On 22/05/14 08:27, Edwin Humphries (text) wrote: > Can anyone suggest a way of testing the download speed of my NBN fibre > connection every hour and logging it? I have an ostensibly 100Mbps > connection, but the speed seems to vary enormously, so an automated > process would be good.
The speed would be expected to vary enormously across the internet, only to nearby (and that pretty much means NSW, QLD or VIC for a user in NSW) servers that themselves have 100Mbit spare would you actually approach 100Mbit. Reasons you might not get 100Mbit, just off the top of my head, almost certainly widely incomplete. But first there's one important thing to know, the bandwidth/delay product, which in very simple terms means that as soon as there's any packet loss at all (and there's always some) the usable throughput is defined by a function of that loss and the latency of the connection. This is why achieving 100Mbit to Australian servers isn't too hard, even with a moderate amount of packet loss, but you can tolerate nearly no loss on a connection to a European server. http://en.wikipedia.org/wiki/Bandwidth_delay_product Your domain: 1. Client device incapable of 100Mbit transfers, still surprisingly common. OS, hardware, and client software all matter. 2. Client device to local gateway not capable of 100Mbit transfers. Wired gigabit ethernet (or *perhaps* 802.11n in an RF quiet environment) is needed for this. A bad ethernet cable may cause this too, always use pre-made (moulded strain relief) cables, humans are not reliable enough to make gigabit ethernet cables. Also, avoid a total cable length above 50m, many lower-end switches/routers can't actually drive ethernet to the full spec distance. 3. Local gateway (What's commonly called a router, industry call CPE), even fairly current gen stuff can struggle at 100Mbit transfer rate, especially if there's a high rate of session creation, or the router suffers from "bufferbloat". Nbnco's domain: 1. Media errors on the fibre, this should be monitored by NBNco. 2. Oversubscription on the fibre, the NBNco fibre is (currently) lit with GPON, which is a 2.5Gb signal (down), normally shared between 32 premises (64 or more is possible, but IIRC not used in .au). This should almost never occur if everyone's only at 100Mbit, even at higher speeds it works surprisingly well. Again, NBNco should know if this happens. 3. Oversubscription between the OLT (fibre head) and the ISP. Shouldn't happen, again monitoring should happen. (Your) ISP's domain: (Actually if you're not with one of the major providers there's a couple of extra interconnect points that can congest as well) 1. Oversubscription on the connection from NBNco to the ISP, this is known to cause some issues, sadly the best writeup of it I can't find. Actually monitoring this is a pain, the ISP can do some bits but are unlikely to do so, and NBNco probably don't either. 2. Congestion within the ISPs access network between the NBNco POI (120 nationally) and the ISP's core POP (usually 1 or 2 per city for all but the very largest). For large ISPs this is highly unlikely, and the smaller guys are covered by the wholesalers who don't save anything (significant) to get it wrong. 3. Congestion within an ISPs core. Unlikely, expect perhaps on inter-state links. 4. Congestion between an ISP and the next ISP in the path. Depending on who's involved this is either very unlikely or guaranteed. In the middle: 1. Did someone put in a stateful firewall which breaks TCP. This is pretty much all of them, this makes things a lot worse in high-latency or high-loss environments. 2. Is the server far away (see bandwidth/delay product above). The end server: 1. Does it have a path into a decent ISP network at > 100Mbit? 2. Can it actually serve at > 100Mbit? (plain static files are fairly easy, dynamic content can get expensive quick). The same caveats about OS, hardware and software apply as for the clients. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
