[clug] how to use traceroute (now: iinet performance)

[Eyal Lebedinsky]

For those still interested. Yesterday I had another support call with iinet. Again we toggled the
modem etc. and then we left it at that, and they were going to see what they could do and call
me the next day.

The surprise was that as I restarted my speed test script following the call
(results updated every 10 minutes here http://members.iinet.net.au/~eyaleb/iinet-speed.png )
the download speed was all the way up, to around the maximum possible on the relevant ADSL
sync speed (also shown on the plot now). I will let the script run a little longer.

It continued this way for over a day so far (since after 6pm yesterday). Must be magic. Or there
really is Dog. Or I have a guardian angel (finally!). I hope it will stay this way now.

Anyway, is it just me (I am on the Melba exchange) or do other sufferers see the same thing?

BTW, they did call back the next day (earlier today) and it was a very short call this time,
with nothing more needed to be done - they did not know that the situation was resolved.

cheers
	Eyal

On 06/27/14 10:21, Eyal Lebedinsky wrote:
> To support my claims, here is the performance (download 10MB from ftp.iinet) of my service for
> the last day or so. The ADSL sync speed is now 5973, so I should be able to get up to about
> 600KB/s, which I did overnight. But the trend this morning is a worry :-(
>
> The trend shows a deep dip 4pm-2am. The ADSL line sync varies, and during this period was:
>
> Jun 25 09:58:08 e5  kernel: ADSL link up, interleaved, us=975, ds=6172
> Jun 26 21:53:22 e5  kernel: ADSL link up, interleaved, us=947, ds=5946
> Jun 26 23:31:52 e5  kernel: ADSL link up, interleaved, us=995, ds=5973
>
> I do not know why the overnight performance was worse on the 26th, compared to today (27th),
> when the logged line speed was similar. I suspect that some modem retraining happened which
> is not properly logged, I did lose ppp connection intermittently a few times that evening.
>
> The plotted download speed if what 'curl' shows as the final transfer average (on the
> progress line). I will keep the script running for a few more days.
>
> I will let iinet do the legwork: http://members.iinet.net.au/~eyaleb/iinet-speed.png
>
> cheers
>      Eyal
>
> On 06/25/14 10:49, Eyal Lebedinsky wrote:
>> On 06/25/14 10:28, Scott Ferguson wrote:
>>> On 25/06/14 09:31, Eyal Lebedinsky wrote:
>>>> I used it before to see what is going on with routing. However, there is
>>>> something going
>>>> on with iinet recently, and a download test from ftp.iinet.net.au ran at
>>>> around 50k/s for
>>>> a line sync of 6-7Mb/s.
>>>>
>>>> I did a 'traceroute ftp.iinet.net.au' and it went all the way to 30
>>>> hops. I added '-m 255'
>>>> and it still went all the way. Looks like some kind of loop between
>>>> 203.0.178.32 (ftp.iinet...)
>>>> and 203.215.4.197 (no DNS). It is still doing this now.
>>>>
>>>> I find this unusual but maybe I do not understand how it works and why
>>>> this is acceptable.
>>>>
>>>> Can anyone explain why this is so and is this normal?
>>>>
>>>> TIA
>>>>
>>>> --
>>>> Eyal Lebedinsky (eyal at eyal.emu.id.au)
>>>
>>>
>>> For your purposes you'll probably find tcptraceroute more useful
>>> (instead of ICMP tracerouting).
>>> e.g. tcptraceroute -n 255 ftp.iinet.net.au
>>> will test the route used for tcp packets, maximum of 255 hops, using the
>>> device and gateway from your routing table. You can specify the gateway
>>> with -g and the interface with -1. By default it uses the IPV from your
>>> routing table, IPV4 can be forced with -4, IPV6 with -6.
>>>
>>> For the purpose of getting a realistic measure of network performance
>>> may I suggest you use the tests from M-Labs (Open Source code):-
>>> http://www.measurementlab.net/tests
>>>
>>> The most useful in your case is Network Diagnostic Test:-
>>> http://www.measurementlab.net/tools/ndt
>>> NOTE: it requires java to use the online version. The downloadable CLI
>>> version is:-
>>> http://code.google.com/p/ndt/source/
>>>
>>> To test the last mile of your broadband use Network Path and Application
>>> Diagnostics:-
>>> http://www.measurementlab.net/tools/npad
>>>
>>> To test from within a LAN use the WRT-based router tool:-
>>> http://www.measurementlab.net/tools/bismark
>>>
>>> To test for application traffic shaping:-
>>> http://www.measurementlab.net/tools/glasnost
>>>
>>> To test for network transparency (ISP shaping/throttling):-
>>> http://www.measurementlab.net/tools/shaperprobe
>>>
>>> To perform reverse tcptracerouting from selected endpoints:-
>>> http://www.measurementlab.net/tools/reverse_traceroute
>>>
>>> To test your DNS performance try the DNS Benchmark tool - workbench.
>>>> From memory you use a SUSe distro - it's probably in your repository,
>>> it's in Debian's:-
>>> https://code.google.com/p/namebench/
>>>
>>>
>>> Kind regards
>>
>> Thanks Scott,
>>
>> tcptraceroute showed that all is well.
>>
>> My issue was that a download from iinet (my ISP) site was running at less than 10% of
>> the sync speed (which itself is low around 6Mb/s).
>>
>> After midnight the speed picked up to full sync, but this morning it is again slowly going down.
>>
>> Fetching http://ftp.iinet.net.au/test100MB.dat
>>      over 1h yesterday evening
>>      11m at 8am today
>>      20m now (10:30)
>> Should take 2-3 minutes at my (slow) sync speed, which it did at around 00:30 this morning.
>>
>> Any other iinet users here?
>>
>> cheers
>>
>> --
>> Eyal Lebedinsky (eyal at eyal.emu.id.au)
>

-- 
Eyal Lebedinsky (eyal at eyal.emu.id.au)