Interpreting WAN quality RRD graph
-
I clicked it and went and made a pot of coffee and a snack while the page loaded ;D
http://www.vodafone.co.nz/about/rural-broadband-initiative/Some parts of the page still not loaded after 2 minutes here… Edit: Wow, the "tower" image loaded just under 3 minutes...
P.S. Reading the page, I seriously don't think they did get it. The issue is absolutely not bandwidth. With similar latency, speed does not matter.
-
Their main server is running off this modem I think:
http://www.youtube.com/watch?v=qHNvp7FfP6E
(I used to use this sort of rig for long haul encrypted digital comms. Just incase end of the world gear in my past jobs)
-
I think Squid and some sort of dynamic content caching system would be the most important thing for someone on a connection like this to have. I really do wish that for things like youtube, hulu, pandora and the whole plethora of semi-questionable content sites out there that pfsense had some sort of out of the box solution to cache them.
-
Their main server is running off this modem I think:
http://www.webpagetest.org/result/130721_PA_856/
Impressive. I think they'd better get out of business soon.
-
Beginnings are always an awkward place. I'm sure they will improve.
I think they should consider static high altitude "Blimp" like satellites for bandwidth.
It faster than towers or satellites and cheaper. Deploy overnight. Can carry enough payload for their entire country on a couple.
Its a no-brainer and yet - it rarely happens… -
I wonder… who's the guy who happens to be in Nepal? Jim? Maybe he could compare that. Maybe moving to Nepal you'd be better off than at NZ, with a nice uncluttered view of Sagarmāthā as a bonus. 8) ;D
-
There are no good bars near an uncluttered view of Sagarmāthā. (and the internet sucks)
I prefer clutter. -
Interesting to hear of how slow grabbing stuff from this part of the world is. Does anyone with the inclination want to try a speed test from either http://speedtest.telecom.co.nz/ or http://www.vodafone.co.nz/broadband/speedtest/ and see how it compares with your expectations?
-
On a sort of related note, you can check average speed for NZ or elsewhere at: http://www.akamai.com/stateoftheinternet/index.html#nui
-
I put an Alix pfSense in Mugu, Nepal on 192Kbps a few weeks ago. Their ping times to any real internet targets range from 900-1200ms, with some up to 3000ms. Packet loss (as reported on the dashboard, or on a typical ping for a few minutes) is nearly always 10-20%. The town telephone exchange is completely on a satellite link (no microwave towers on mountains yet) and is overloaded. They put in ADSL but they don't have enough satellite bandwidth at peak (or ordinary) times, so calls drop out, internet is slow…
But I have never seen 16000ms! I am rather surprised that a router anywhere would have a packet buffer that would hang on to packets for that long in a queue and finally transmit them on a slow link. In my case in Mugu, once the software has waited 5000ms for a reply it can give up - the packet has been dropped/lost somewhere in the sending and replying.
Good luck getting all those sheep online :) -
http://www.vodafone.co.nz/broadband/speedtest/ and see how it compares with your expectations?
WiMax connection:
vs.
VDSL with two IPTV STBs (which causes the sucky ping)
vs.
-
I think Squid and some sort of dynamic content caching system would be the most important thing for someone on a connection like this to have. I really do wish that for things like youtube, hulu, pandora and the whole plethora of semi-questionable content sites out there that pfsense had some sort of out of the box solution to cache them.
Yeah, I find it frustrating that a lot of educational resources which would be of benefit in our local schools (which have the same poor bandwidth as us) are posted to Youtube. Which, firstly, seems to be a waste of bandwidth in terms of efficiency of imparting information - me, I prefer static text and diagrams, but most posters don't go to the trouble to make the content of their videos accessible by other means. Secondly, the reality is that they're on there and teachers expect that resource to be available but Youtube and their ilk aren't cache friendly. So then you have to decide whether to spend quite a bit on http://cachevideos.com/ to be able to utilise it easily.
-
No Java thanks. I'm trying to cut back.
Too much Java makes me jittery.
Yeah - that speed test sucks. -
I put an Alix pfSense in Mugu, Nepal on 192Kbps a few weeks ago. Their ping times to any real internet targets range from 900-1200ms, with some up to 3000ms. Packet loss (as reported on the dashboard, or on a typical ping for a few minutes) is nearly always 10-20%. The town telephone exchange is completely on a satellite link (no microwave towers on mountains yet) and is overloaded. They put in ADSL but they don't have enough satellite bandwidth at peak (or ordinary) times, so calls drop out, internet is slow…
But I have never seen 16000ms! I am rather surprised that a router anywhere would have a packet buffer that would hang on to packets for that long in a queue and finally transmit them on a slow link. In my case in Mugu, once the software has waited 5000ms for a reply it can give up - the packet has been dropped/lost somewhere in the sending and replying.Thanks. Very interesting to hear from someone with hands-on experience from similar locations. Afraid VF NZ should be ashamed.
Good luck getting all those sheep online :)
ROTFLMAO! You owe me a new keyboard, mine if full of coffee now! ;D :D ;D
P.S. Yeah, squid even on a recycled old desktop machine would help significantly.
-
Good caching is such a universal need for most of the world, one would think that caching of dynamic content would be free (like free beer) and free as in freedom. You need it for sure. Most of the world does actually.
Squid is a nice tool and, contrary to many people's experiences, I've found that when configured as a transparent proxy it makes my browsing rock solid. Especially Hulu. God only knows why because its not caching hulu content, but its undeniable. No endless circles or pauses when I'm running squid. Very strange.But this guy - He needs alot better and inclusive cache than a standard squid proxy. He needs something that sucks in and and saves everything for later.
-
I just wrote that company a note on how they should give it away for free to schools in bandwidth deprived areas.
Who knows if they will reply… -
Good luck getting all those sheep online :)
Put them nose to tail, a bit of no.8 wire, and I'm sure we could use some of that dark fibre
-
Just wondering if anyone else can post results from pinging their gateway from a pfSense shell while running a sustained download (e.g. pick a fairly large size from http://testmy.net/download ) to see if there's any noticeable difference to their normal results?
-
icmp_req=119 ttl=64 time=0.304 ms pinging my public IP
icmp_req=34 ttl=64 time=0.391 ms pinging my LAN ipDuring a 14.5 Mbps download.
Its pretty much the same downloading or not. No difference for me.
Following instructions this time, I pinged my gateway IP (-;
icmp_req=18 ttl=126 time=8.11 ms Not dowloading
icmp_req=28 ttl=126 time=88.5 ms Downloading (MOCA is a POS when its loaded down. I plan to connect directly to ONT at this location soon) -
Just wondering if anyone else can post results from pinging their gateway from a pfSense shell while running a sustained download (e.g. pick a fairly large size from http://testmy.net/download ) to see if there's any noticeable difference to their normal results?
I guess not. 2.1RC0 on Alix:
PING www.google.com (173.194.35.84): 56 data bytes 64 bytes from 173.194.35.84: icmp_seq=0 ttl=58 time=3.096 ms 64 bytes from 173.194.35.84: icmp_seq=1 ttl=58 time=2.447 ms 64 bytes from 173.194.35.84: icmp_seq=2 ttl=58 time=2.657 ms 64 bytes from 173.194.35.84: icmp_seq=3 ttl=58 time=2.726 ms 64 bytes from 173.194.35.84: icmp_seq=4 ttl=58 time=2.544 ms 64 bytes from 173.194.35.84: icmp_seq=5 ttl=58 time=2.655 ms 64 bytes from 173.194.35.84: icmp_seq=6 ttl=58 time=2.330 ms 64 bytes from 173.194.35.84: icmp_seq=7 ttl=58 time=2.720 ms 64 bytes from 173.194.35.84: icmp_seq=8 ttl=58 time=2.245 ms 64 bytes from 173.194.35.84: icmp_seq=9 ttl=58 time=2.499 ms