Herbie, We don’t know its meaningless. Why is it meaningless? That’s new to me. Please feel free to explain in non computer understander terms if ya can for me.
The speedtest measures not just your link to CityTel but all the way to the server you choose. You have no idea where and slowdown is. Pick several different servers, you get a little better idea. But you’re still measuring the link out of Rupert.
I can tell you that historically all the tests I’ve ever done from central BC sucked on the upload to the Rupert server. Even when it was on Navigata and so was I.
As far as throttling goes, speedtesting means nothing at all. Most machines throttle you on your overall bandwidth use (not the protocols used), the number of simultaneous connections (for the dopes than run SlimeWire with 10 fullspeed downloads and the default 20 uploads at max speed) and are set to route speedtest sites wide open.
You also have to do speedtest right. Unplug from your router so you know no one else is on the link. Shut off every other process, you can’t be running SlimeWire or BitTorrents AND try the speedtest. Half the ppl we do rollouts for don’t even bloody know they’re running P2P software, MSN, Yahoo and Skype every time they start their computer.
Had a Vista laptop and the damn thing could barely browse the Net if torrents were running…
A tad more: the server’s pipe and the pipe out of town are going to be bigger than yours so it seems logical the tests would indicate the slowpoint at your link. It should, but there’s routing involved too.
From the number of you complaining in Rupert and the crappy uploads to Rupert there’s no doubt your main link out of town is saturated. When HTMF was hosted there it was slow to load here and posting was OMG wait for it…
I hear that our town hits saturation on the fibre link often, and we’re WAY smaller than Rupert. Every Monday I hear a couple tales of mail that didn’t arrive and how the senders got ‘server not responding/be found’ errors on locally hosted sites.
Thanks for the info.
[quote=“herbie_popnecker”]
The speedtest measures not just your link to CityTel but all the way to the server you choose. You have no idea where and slowdown is. Pick several different servers, you get a little better idea. But you’re still measuring the link out of Rupert.[/quote]
Unless you use Citywest’s Speedtest server. Then you are getting a picture of the bandwidth between your house and Citywest, no outside network involved.
[quote=“herbie_popnecker”]
From the number of you complaining in Rupert and the crappy uploads to Rupert there’s no doubt your main link out of town is saturated. When HTMF was hosted there it was slow to load here and posting was OMG wait for it…[/quote]
Yeah, maybe part of that was that you were sharing bandwidth with my house as well 
HTMF is actually faster for people in Rupert too, despite being 14 or 15 hops away now. Not having to compete with me for bandwidth, and not sharing a server that I used for my LAN as well probably has something to do with it.
so mig what is truly the best way to first , find out if the cable , splitters, and the modem are not the problem . Then second find out the tru amount of netspeed that we get to out house and i have done a few tracert’s in command prompt and i was checking the gaming server that i use frequently and it always has high (175) ping in random hops different every time can you help tell me what is causeing that ?
thanks mig this is what it said " Summary of Noteworthy Events –
Minor Aberrations
Certain protocols are blocked in outbound traffic
The measured network latency was somewhat high
The measured time to set up a TCP connection was somewhat high
None of the server’s bandwidth measurement packets arrived at the client
Network packet buffering may be excessive
Virus filtering appears to be present on your host or network
Your computer’s clock is slightly slow
Address-based Tests +
NAT detection: NAT Detected
DNS-based host information: OK
Reachability Tests –
TCP connectivity: Note
Direct TCP access to remote FTP servers (port 21) is allowed.
Direct TCP access to remote SSH servers (port 22) is allowed.
Direct TCP access to remote SMTP servers (port 25) is allowed.
Direct TCP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote HTTP servers (port 80) is allowed.
Direct TCP access to remote POP3 servers (port 110) is allowed.
Direct TCP access to remote RPC servers (port 135) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote NetBIOS servers (port 139) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote IMAP servers (port 143) is allowed.
Direct TCP access to remote SNMP servers (port 161) is allowed.
Direct TCP access to remote HTTPS servers (port 443) is allowed.
Direct TCP access to remote SMB servers (port 445) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote SMTP/SSL servers (port 465) is allowed.
Direct TCP access to remote secure IMAP servers (port 585) is allowed.
Direct TCP access to remote authenticated SMTP servers (port 587) is allowed.
Direct TCP access to remote IMAP/SSL servers (port 993) is allowed.
Direct TCP access to remote POP/SSL servers (port 995) is allowed.
Direct TCP access to remote SIP servers (port 5060) is allowed.
Direct TCP access to remote BitTorrent servers (port 6881) is allowed.
Direct TCP access to remote TOR servers (port 9001) is allowed.
UDP connectivity: OK
Basic UDP access is available.
The applet was able to send fragmented UDP traffic.
The applet was able to receive fragmented UDP traffic.
Direct UDP access to remote DNS servers (port 53) is allowed.
Direct UDP access to remote MSSQL servers (port 1434) is blocked.
This is most likely due to a filtering rule against the Slammer worm.
Path MTU: OK
The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1500 bytes.
Network Access Link Properties –
Network latency measurements: Latency: 700ms Loss: 1.0%
The round-trip time (RTT) between your computer and our server is 700 msec, which is quite high. This may be due to a variety of factors, including a significant distance between your computer and our server, a particularly slow or poor network link, or problems in your network.
We recorded a packet loss of 1.0%. This loss rate is within the range commonly encountered and not usually inducing significant performance problems. Of the packet loss, at least 1.0% of the packets appear to have been lost on the path from your computer to our servers.
TCP connection setup latency: 730ms
The time it takes for your computer to set up a TCP connection with our server is 730 msec, which is quite high. This may be due to a variety of factors, including a significant distance between your computer and our server, a particularly slow or poor network link, or problems in your network.
Network background health measurement: no transient outages
During most of Netalyzr’s execution, the applet continuously measures the state of the network in the background, looking for short outages. During testing, the applet observed no such outages.
Network bandwidth measurements: Download 8.2 Kbit/sec
None of the bandwidth measurement packets sent between the server and client arrived at the client when testing the uplink, which prevented us from measuring the available bandwidth. One possible reason for this is dynamic filtering by access gateway devices. Another possibility is simply a transient error.
During this test, the applet observed 6 duplicate packets.
Your Downlink: We measured your downlink’s receiving bandwidth at 8.2 Kbit/sec. This rate could be considered quite slow, and will affect your user experience if you perform large transfers.
Network buffer measurements: Uplink is good, Downlink 5000 ms
We were not able to produce enough traffic to load the uplink buffer, or the uplink buffer is particularly small. You probably have excellent behavior when uploading files and attempting to do other tasks.
We estimate your downlink as having 5000 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large downloads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large downloads at the same time. "
sorry too much info lol i really dont know where to start
Good link MiG!
Direct 5.8Ghz link to Navigata’s 10Mb POP here (AP shows 36Mb link 0% packet loss @2346 bytes to POP gateway}.
Shows 15.5% packet loss on test
100ms ping to test server
5100ms of buffering.
Only got 1.7Mb down, 2.4Mb up , speedtest to San Francisco 8.57 down 4.15 up 37ms ping
That’s a lot of packet loss and buffering on their end.
This is their second release of this tool. First came out in June last year. I have used it a few times since I first saw their initial release announcement back then. Nice tool.
One of the guys involved in this project, from what I understand, works for LBL @ Berkeley.