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

Sun Jun 29 22:22:24 MDT 2014

On Sat, Jun 28, 2014 at 09:22:55PM +1000, Eyal Lebedinsky wrote:
> 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?
> 

Hi Eyal

I am 600m from the Melba exchange. See previously posted performance test.

Cheers
Anthony

> 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)
> -- 
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux