-- from your post: traceroute -4 speedtest-sgp1.digitaloc...

mdk
Legendary Grand Master

@element3 -- from your post:

traceroute -4 speedtest-sgp1.digitalocean.com

Tracing route to speedtest-sgp1.digitalocean.com [159.89.192.182]
  4   11 ms rc1wt-be40.wa.shawcable.net [66.163.68.18]
  5   29 ms rc3sj-be60.cl.shawcable.net [66.163.75.90]
  6   29 ms gi5-2.sjc-core01.net.telstraglobal.net [206.223.116.11] 
  7    29 ms i-92.eqnx-core02.telstraglobal.net [202.84.247.18]
  8  229 ms i-25008.sgpl-core03.telstraglobal.net [202.84.144.193]
  9  231 ms  i-93.istt04.telstraglobal.net [202.84.224.190]
10 233 ms unknown.telstraglobal.net [210.176.138.133]
11 231 ms 138.197.245.11
12 * * * Request timed out.

Lots of "lag" between San Jose California to TELSTRA on the other side of the Pacific Ocean.

Downloading that file to a computer within Australia could be much faster than your download to a computer in Canada.

 

0 Kudos
Reply
Loading...

-- for your file:  https://mirror.csclub.uwaterloo.ca/ubu...

mdk
Legendary Grand Master

@element3 -- for your file: 

https://mirror.csclub.uwaterloo.ca/ubuntu-releases/22.04.1/ubuntu-22.04.1-live-server-amd64.iso

it downloaded at about 26 Mbits/second.


Most Canadian universities have two connections to the Internet:

* CANARIE.CA -- fiber-optic cable running as fast as possible -- not rate-limited -- for university-to-university high-speed connections for "research" purposes,

* the "commercial" Internet -- through Shaw or Bell or Rogers -- that is charged by the Mbyte, and usually is rate-limited and rate-capped, to control the monthly usage costs to the university.

As a Shaw customer:

traceroute  -4 mirror.csclub.uwaterloo.ca

  5 12 ms rc2wt-be18-1.wa.shawcable.net [66.163.64.82]
  6 27 ms rc3no-be100.cg.shawcable.net [66.163.75.234]
  7 45 ms rc2nr-be110-1.wp.shawcable.net [66.163.76.58]
  8 90 ms rc3fs-be25.mt.shawcable.net [66.163.76.22]
  9 67 ms 66.163.65.58
10 66 ms 209.148.235.213
11 67 ms 209.148.230.46
12 70 ms 24.156.146.190
13 70 ms unallocated-static.rogers.com [72.142.108.182]
14 * * * Request timed out.

Vancouver -> Calgary -> Winnipeg -> Montreal -> (other) -> Rogers -> U. of Waterloo

Your download does not seem to transit over the CANARIE network.

So, it probably is the U. of Waterloo (or that specific server) that is rate-limited, not your Shaw connection.

 

0 Kudos
Reply
Loading...

namely the "Elastic Cloud" by Amazon. So, that server is...

element3
Grasshopper

namely the "Elastic Cloud" by Amazon.

So, that server is sending at 100 Mbits/second, even though you have 500 Mbits/second via Shaw.

Could you please explain where do you get these numbers from and how you conclude such conclusions?

0 Kudos
Reply
Loading...

-- please explain ... To elaborate on what I wrote last F...

mdk
Legendary Grand Master

@element3 -- please explain ...

To elaborate on what I wrote last Friday:

The image you posted was:

Capture.JPG

has "14.5M" below "Average Dload", and "15.4M" below "Current Speed" and "1000M" below "Total".

If the server was actually sending at 1000 Mbits/second, then sending 1000M would take about 8 seconds, because each byte sent is actually 8 bits, plus per-packet "overhead". But, "time spent" plus "time left" is much more than 8 seconds. This shows that the server is sending at about 10% of 1000 Mbits/second.

If you have "Fibre+ 500" or "Fibre+ 750" service from Shaw, you cannot receive data at "Fibre+ 1000" speed.

However, each "packet" sent over the Internet has "header" information, which is "overhead", but it ensures that any "out-of-order" received packets can be unscrambled and put back into their proper order.

 

0 Kudos
Reply
Loading...

Thanks for the explanation but that "1000M" below "Total"...

element3
Grasshopper

Thanks for the explanation but that "1000M" below "Total" is the files size and NOT server network capacity, The server I setup has 5gbps network capacity, I intentionally choose a high capacity server to rule out bottle necking from the server side. if you divide 1gb file size by roughly 14mb then the time left makes sense. 
About the Ubuntu server, those are extremely high speed servers too, I'm not sure why trying to explain how things work in Canada and such, at the end of the day not a single consumer goes "huh, so my packet should travel through this and that route to get here faster!" as it's not our job to care about those stuff, isn't that why we pay ISPs? With due respect if I would want to do that then I would establish my own ISP and provider high quality internet to people! All I care about is that we were told by Shaw Communication that we'll be getting 600mb speed but in reality we're getting about 150mb, and yes those are Megabits and not Megabytes!
After all, I find your suggestions biased as it seems you include irrelevant information and leave out relevant information to direct the manner towards your desired conclusion, tbh you talk just like any other Shaw representative (not judging, just saying).
Thanks for trying though, I appreciate your effort.

0 Kudos
Reply
Loading...

-- Thanks for the explanation but that "1000M" below "Tot...

mdk
Legendary Grand Master

@element3 -- Thanks for the explanation but that "1000M" below "Total" is the files size and NOT server network capacity.

When I downloaded that file, the size of the was 1000 megabytes -- note the "M", which is not an "m".

But, that server is not currently responding, so I cannot repeat the download.

 

from the server side. if you divide 1gb file size by roughly 14mb then the time left makes sense. 

So, are you getting 14 megabits/second for the download speed, or 116 (8*14) megabits/second ?

 

I'm not sure why trying to explain how things work in Canada

You tested servers in Australia, and in the USA, and in Canada. Obviously, moving packets across the Pacific Ocean takes longer than moving packets across Canada.  So, when running "speed-tests", you have to understand compensate for the location of those servers away from your client computer.

 

All I care about is that we were told by Shaw Communication that we'll be getting 600mb speed but in reality we're getting about 150mb, and yes those are Megabits and not Megabytes!

Run the Shaw Speed Test, which, for you, will connect to a high-speed server in Vancouver, and you should get 600 Megabits/second. If you do not get anything near that speed, then something is wrong with your network connection, or with your computer.  

On my "Shaw Fibre+ 500" service, I get 546.1 for download, and 104.8 for upload -- slightly more than the 500/100 speeds that are promised in my Shaw contract.

 

I find your suggestions biased as it seems you include irrelevant information and leave out relevant information

If you do not understand the relevance of part of my message, that is not my fault. If I have left out relevant information, please supply that information.

 

you talk just like any other Shaw representative (not judging, just saying).

Really?  By saying it, you are judging.

I have never worked for Shaw. I have never been employed by Shaw. Shaw has not authorized me to speak on their behalf.

 

0 Kudos
Reply
Loading...

> When I downloaded that file, the size of the was 1000 m...

element3
Grasshopper

> When I downloaded that file, the size of the was 1000 megabytes -- note the "M", which is not an "m". But, that server is not currently responding, so I cannot repeat the download.

> from the server side. if you divide 1gb file size by roughly 14mb then the time left makes sense.

> So, are you getting 14 megabits/second for the download speed, or 116 (8*14) megabits/second ?

I still don't understand what you're trying to prove or say here, I uploaded a 1gb file to a server with 5gb network capacity and downloaded the file to my workstation and I was getting 14 megabytes which is equal to roughly 112megabits. If you divide 1000(file size) by 60 seconds (time left) it'll give you roughly 16 megabytes which is inline with the image.

I'm not sure why trying to explain how things work in Canada

> You tested servers in Australia, and in the USA, and in Canada. Obviously, moving packets across the Pacific Ocean takes longer than moving packets across Canada. So, when running "speed-tests", you have to understand compensate for the location of those servers away from your client computer.

Not necessarily, in computer networking packets route through the faster route, actually you might receive a packet going through 5 hops within Australia, USA, China, Canada and Singapore faster than a packet going through 5 hops within Canada. The location will have impact on your latency but it might not have any impacts on your speed and it actually might be faster to route them through the faster route.
On top of that, you again choose to leave out my argument about consumers, intentionally or unintentionally.

> Run the Shaw Speed Test, which, for you, will connect to a high-speed server in Vancouver, and you should ge...

Running Shaw Speed Test on Shaw servers does not prove anything, Shaw can simply run an script that'll return my agreement as my bandwidth based on my IP address or give me full bandwidth access inside Shaw servers but bottle neck me as soon as packets want to leave their servers, after all they're the ones who provide the IP and routing service; it also does not in any shape or form represent real world experience, Do you watch YouTube on Shaw server in Vancouver? Do you game on Shaw servers in Vancouver? Do you Netflix on Shaw server in Vancouver? Do you read Reddit on Shaw Servers?
Shaw's job is to provide consumers with the fastest routing service based on their service agreement.
This argument that you're having is the exact same argument I had with the Shaw rep on chat! That's why I say you talk like them, but I believe you if you say you're not affiliated with them.

> If you do not understand the relevance of part of my message, that is not my fault. If I have left out relevant information, please supply that information.
I definitely can make sense of your arguments, you bring is traceroute which is corresponds to latency and you argue that it'll affect the speed because things go to Australia.


These are only a handful of irrelevant information that you're providing:

> However, such fast routing is only one factor. Your video-experience also depends on the YouTube file-server being able to "push" out data to thousands of simultaneous end-user computers, including you; such a lack of capacity is the reason for "jitter" and "buffering" while you are watching a video-stream.
Not relevant because if you understand the nature of my test you also understand this the exact reason I tested many different servers, so you can not argue this is Google or Apple or this or that.

It is possible that there is a "CAT-5" Ethernet cable, which maxes-out at 100 Mbits/second, connected to that computer, instead of a "CAT-5e" cable that maxes-out at 1000 Mbits/second.

It is possible that the owner of the computer has 100 MBit/second Ethernet service.

It is possible that the Ethernet network adapter inside the owner's computer is a 10/100 adapter, not a 10/100/1000 adapter.

So, despite your "fast" Shaw connection, that server is only sending data at 100 Mbits/second.

By the speed you're getting you concluded that it is the Cable that is limiting the speed before anything

It is also possible they're using 10GB network, It is also possible they use fiber instead of cat cables, it's also possible that SLOW "Shaw" servers are the reason for both our bottlenecks, There are unlimited possibilities here and again if you understand the nature of my test you understand I tested many different servers to rule these possibilities out.

> Namely, faster than a 10 Mbit/second Ethernet adapter,
but not as fast as a 10/100 Ethernet adapter.

> The trace shows a "lag" between New York (USA) and Nuremberg (Germany). That is expected.

Here is another one, you say internet speed is low because your traceroute shows a ping jump from 91ms to 172ms where in regality that is an irrelevant factor even if you GAME as it does not that much of an impact on the speed.

>namely the "Elastic Cloud" by Amazon.

So, that server is sending at 100 Mbits/second, even though you have 500 Mbits/second via Shaw.

I am still amazed at you becoming to that conclusion.


> You talk just like any other Shaw representative (not judging, just saying).

> Really? By saying it, you are judging.

At this point I don't judge anymore, you talk just like Shaw reps or at least your logic works like them.


0 Kudos
Reply
Loading...

I am willing to continue this "discussion", but if you ca...

mdk
Legendary Grand Master

I am willing to continue this "discussion", but if you call it an "argument", and use ad hominen attacks, then I'm done.

> I uploaded a 1gb file to a server with 5gb network capacity

No, you uploaded a 1GB file -- 8 times the size of a 1gb file.

> downloaded the file to my workstation and I was getting 14 megabytes which is equal to 112 megabits.

It is good that you agree with what I stated, because there are exactly 8 bits per byte.

> If you divide 1000(file size) by 60 seconds (time left) it'll give you roughly 16 megabytes which is inline with the image.

Yes, 1000 Megabytes divided by 60 seconds is about 16 Megabytes (equivalent to 128 Megabits) per second, which is about 1/4 of the speed that you are getting from Shaw.

Obviously, moving packets across the Pacific Ocean takes longer than moving packets across Canada. So, when running "speed-tests", you must have the understanding to compensate for the location of those servers that are far away from your client computer.

> Not necessarily, in computer networking packets route through the faster route,

Not necessarily. Each router knows which paths have which loads, and which paths have the least/most cost for transmitting each packet.
Look again at the packet-trace from Shaw (in Vancouver) to U. of Waterloo that bridges over to Rogers.
The CANARIE path from UBC to U. of Waterloo is "zero-charged", but CANARIE only connects one research institution to the other research institutions.
The "commercial Internet" path from Shaw (Vancouver) to the U. of Waterloo is the only route that completes the connection, even though it is a much-slower connection than any CANARIE connection.

> actually you might receive a packet going through 5 hops within Australia, USA, China, Canada and Singapore faster than a packet going through 5 hops within Canada.

I doubt it. Show me some proof.

Crossing the Pacific Ocean from Vancouver to Australia takes time, even when packets are moving at the speed of light.
Example of tracing from Vancouver towards the U. of Sydney, New South Wales, Australia.

tracert -4 usyd.net.au

Tracing route to usyd.net.au [103.67.235.120]

4 11 ms rc1wt-be40.wa.shawcable.net [66.163.68.18]
5 29 ms rc3sj-be60.cl.shawcable.net [66.163.75.90]
6 30 ms swt01.sjc02.ca.vocusconnect.net [206.223.116.227]
7 228 ms be203.cor01.syd11.nsw.vocus.network [114.31.199.40]
8 229 ms be201.lsr01.dody.nsw.vocus.network [103.1.77.24]
9 226 ms be803.lsr01.prth.wa.vocus.network [103.1.76.147]
10 230 ms be200.cor01.per04.wa.vocus.network [103.1.77.113]
11 230 ms be101.bdr03.per02.wa.vocus.network [114.31.206.37]
12 235 ms ip-78.221.103.123.VOCUS.net.au [123.103.221.78]
13 * * * Request timed out.
14 * * * Request timed out.
15 230 ms xe-2-0-0-u166.border1.per01.ds.network [103.212.217.79]
16 * * * Request timed out.
17 231 ms sp-hosting01.per01.ds.network [103.67.235.120]

Trace complete.

> The location will have impact on your latency but it might not have any impacts on your speed.

Some of the latency shows up because the trans-Pacific route is heavily-loaded -- packets have to "wait their turn".

> it actually might be faster to route them through the faster route.

The operative word is "might".

The most important factor is "cost" -- in the USA, if you pay a toll, you get to use the faster/better highway.
On the Internet, routing through any "faster route" is ignoring the higher cost of using that "faster route".

We're back to Shaw (Vancouver) to the U. of Waterloo.
Certainly, it would be possible to route through the "Packet Interchange" at SFU Harbour Centre, crossing-over to the CANARIE network, and then speedily to the U. of Waterloo's connection to CANARIE.


But, Canada's telephone-companies, who own the fiber-optic cables running across Canada, are DONATING their unused capacity to CANARIE, exclusively for use by research institutions.


Shaw charges their customers (Internet Service Providers), by the packet, for access to Shaw's own fiber-optic network.

> you again choose to leave out my argument about consumers, intentionally or unintentionally.

Yes, it is "either" intentionally or unintentionally. But, what's your point?

> Running Shaw Speed Test on Shaw servers does not prove anything,

That is incorrect. Shaw's site lets you choose from different hosts on Shaw's network: Victoria, Vancouver, Kelowna, Calgary, Edmonton, and Winnipeg.
Choose a different host, and rerun the test. You'll see that the more-distant the host is from Vancouver, the lower the reported speeds.

> Shaw can simply run a script that'll return my agreement as my bandwidth based on my IP address or give me full bandwidth access inside Shaw servers.

Conspiracy theory? Shaw could, but you have not shown any evidence that they are doing so.

Note that the only "servers" on Shaw's network that you may access are the Shaw web-sites, and Shaw's mail-servers. You cannot access the Shaw servers that are the "routers".

> bottle neck me as soon as packets want to leave their servers, after all they're the ones who provide the IP and routing service.

Yes, Shaw "owns" multiple ranges of IP-address, and Shaw has their own routers (including in Victoria, Vancouver, Kelowna, Calgary, Edmonton, Winnipeg, and smaller cities such as Nanaimo and Kamloops).

Shaw has routers "everywhere", because customers "anywhere" want to connect to the Internet.


Shaw also connects to various "packet-interchange" sites, where your packets cross-over to other networks (e.g., Rogers, Bell, Canarie, and the USA's "Internet III").
The routers inside those other networks are NOT controlled by Shaw/Bell/Rogers.

> it also does not in any shape or form represent real world experience,

Evidence, please.

> Do you watch YouTube on Shaw server in Vancouver?

Shaw has two types of servers. One is for their own web-sites & mail-servers, and one for their packet-routers.
So, to answer your question, the packets from the YouTube servers do go through their packet-routers in Vancouver, on their way to my computer.

> Do you game on Shaw servers in Vancouver?

If I were to "game", the packets would again flow through Shaw's packet-routers in Vancouver to the "game-servers" (California? Illinois?).

> Do you Netflix on Shaw server in Vancouver?

Same answer: if I were a customer of Netflix, the packets will flow through Shaw's packet-routers in Vancouver, on their way to the Netflix file-servers co-located in the Amazon Elastic Cloud Service (ECS).

> Do you read Reddit on Shaw Servers?

If I had a Reddit ID, the packets would flow through Shaw's packet-routers in Vancouver.

> Shaw's job is to provide consumers with the fastest routing service based on their service agreement.

Not true. Shaw's business plan is to make money.
If you are happy with "Fibre+ 10", Shaw charges you less per month than for "Fibre+ 100".
Similarly, your local Ford dealer sells different vehicles at different prices, based on which vehicle the customer chooses, and based on how much the customer wants to pay.

> you bring is [in?] traceroute which is corresponds to latency and you argue that it'll affect the speed because things go to Australia.

Yes, that is correct. One of the servers you tested is located in Australia.

On the Internet, latency is caused by the physical length of the cables between North America & Australia, and by the number of simultaneous connections of customers in North America to those servers somewhere in Australia.
In real life, if you drive from Vancouver to Richmond, the kilometers you travel will be less than driving from Vancouver to Kelowna -- the extra distance & time is "latency".
If you drive from Vancouver to Richmond after 4 PM on a weekday, it will take much longer than driving the same route at 9 AM on a Sunday, due to much less traffic congestion than during "rush-hour".
That "load" on the route also contributes to "latency".

> These are only a handful of irrelevant information that you're providing:

Irrelevant? I disagree.

> if you understand the nature of my test you also understand this the exact reason I tested many different servers,

Yes, you chose geographically diverse servers (Australia, USA, and Ontario).
All you proved is that different routes have different latency values, and different transmission speeds on those servers.

> It is possible that the owner of the computer has 100 MBit/second Ethernet service.

True. If they do, then a "CAT-5" Ethernet cable is NOT a "bottle-neck" on their service.
However, if the owner of the computer has a 10/100/1000 network adapter, and uses a "CAT-5" cable, they are capped at 100 Mbits/second, by the cable.

It is possible that the Ethernet network adapter inside the owner's computer is a 10/100 adapter, not a 10/100/1000 adapter.

Despite your "fast" Shaw connection for receiving packets, it is possible that a server is transmitting data at 100 Mbits/second.

> It is also possible they're using 10GB network.

True.

> It is also possible they use fiber instead of Ethernet cables.

True.

Note that Shaw uses fiber-optic cables for its "backbone" network, and uses coaxial-cables between the telephone-pole into your home, and the only Ethernet cables are between the Shaw cable-modem and your computer.

> it's also possible that SLOW "Shaw" servers are the reason for both our bottlenecks.

I already mentioned that Shaw has two types of servers: one for their web-sites & mail-servers, and one for their routers.
Shaw's routers that handle the Vancouver-Seattle connection are faster, and more expensive, than the Shaw routers in your neighbourhood.
I truly doubt that any of those routers are "bottle-necks".

Note that all the traceroute outputs that I have included show 8 to 20 milliseconds for "routing" packets. That is "fast" routing.


In the past few years, within this forum, I have read about one exception.
Shaw's routers in Edmonton handle all the packet traffic from north-east BC, northern Alberta, and as far east as Lloydminster.
Shaw users outside of Lloydminster have complained about large latency values when "gaming",
because Shaw's routers in Edmonton simply had too much traffic, and thus introduced latency when packets where going through Edmonton to those game-servers.
If was necessary for Shaw to spend money to upgrade to faster routers, to alleviate that bottle-neck.

Big routers are not cheap!

> There are unlimited possibilities here

Yes, I agree. But, given your evidence, I have given reasonable interpretations for your "raw-data".

> if you understand the nature of my test you understand I tested many different servers to rule these possibilities out.

I disagree that your testing produced sufficient data to justify your conclusions.
For example, if you were to have a friend living near the U. of Waterloo, or in Seattle, who would run the same tests, then the data that they would collect would be beneficial to augment your data.

> you say internet speed is low because your traceroute shows a ping jump from 91ms to 172ms
> where in regality [reality?] that is an irrelevant factor

I do not understand why you call it "irrelevant".
Crossing the Atlantic Ocean is a long run of fiber-optic cable, and just one of a few cables that connect North America to Europe.
Again, the load on those few trans-Atlantic links is large, and that "load" also contributes to the latency of packets.

> even if you GAME as it does not that much of an impact on the speed.

Ask a "gamer" -- low latency is what the gamer needs to be a winner. Large latency values are "game-over".

Enough for one message.

0 Kudos
Reply
Loading...
TALK TO US
We're here to help