OK people... this is really interesting.. if you have a dedicated server, let's have all the numbers here... Everybody who has posted, will you repost it again here? Everybody else is welcome (including those having shared/virtual accounts).

Note: please also tell us who is your NOC...

ftp to ftp.uu.net
login: anonymous
password: your email
try to download the file: [/b]uumap.tar.Z[/b] (8.5 Mbyte in size) - If you don't know how to do this: once you are logged in into ftp.uu.net, do "get uumap.tar.Z"
That's all... spit out the numbers now....

First server: colocated at Interserver.net
Download speed: 440 Kbyte/s (1pm EST) - 2000 Kbyte/s (~11:00pm EST). Burst anywhere from 3.5 Mbps - 16 Mbps.

Second server: colocated at weinbar.com
Donwload speed: has been very consistent at 380 KByte/s (any time). Burst to about 3 Mbps.

Well, I am pretty satisfied with these numbers.... Quite all right....

How about yours? (yea, please repost here... so that we can have a single page where we can share these fun info).

cheers,
:beer:


[Edited by dektong on 03-30-2001 at 11:34 AM]

Dedicated server from skynetweb: 6-7Mbps.
Dedicated server from rackspace: 1.5-1.7Mbps.

One thing which might be relevant is that the skynetweb server is about 4.5ms away from ftp.uu.net while the rackspace server is about 65ms away -- TCP performance suffers in the presence of high latency when there are either short connections, any packet loss, or limited buffers.

[Edited by cperciva on 03-29-2001 at 09:12 PM]

Results from Verio (digitalNATION)

150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 14.5 secs (5.7e+02 Kbytes/sec)

From my workstation. Connected to my NOC's BW

200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 6.98 secs (1.2e+03 Kbytes/sec)

My host is serverhost.com

I downloaded uumap.tar.Z from ftp.uu.net via ftp.
Below is what it output after it had finished

8520221 bytes received in 16.7 secs (5e+02 Kbytes/sec)

That seems good to me, an 8.5MB file in 16.7 secs, about 4Mbit/s

By the way my server is on a 10Mbit/s link.

on vdi, i used to get like 3 megs a second. those were the days :(

catalog.com: 510 Kbytes/sec
dialtone: 470 Kbytes/sec
weinbar: 330 Kbytes/sec
@home cable modem: 161 Kbytes/sec

I've seen servers 'burst' to over 70Mbit (download linked to slashdot).
I've also heard of a cluster of servers saturate Exodus's crosscontinental connectivity (over 500Mbit). Exodus shut the servers down without warning.

Just two interesting tidbits.

Cheers,

Raj Dutt

nopzor, it is much easier to use lots of bandwidth when you have many TCP connections at once. When you are sharing a bottleneck with many other flows -- exactly the case of Exodus's crosscontinental links you mention -- TCP will share the bandwidth equitably on a per-flow basis. If you open up two connections at once, you can download at twice the rate -- which was one of the major advantages of having downloads split into floppy-disk-sized chunks back when that was still done.

Originally posted by cperciva
TCP will share the bandwidth equitably on a per-flow basis. If you open up two connections at once, you can download at twice the rate -- which was one of the major advantages of having downloads split into floppy-disk-sized chunks back when that was still done.

TCP doesn't even address QoS or any sort of IP throttling. It's simply an error/flow control layer that is added onto IP.

Downloading 2 files from the same location at once will not result in 100% faster combined throughput (unless the _only_ bottleneck is an artificial throttle on the ftp server side)

Am I misunderstanding what you are trying to say?

Cheers,

Raj Dutt

Originally posted by nopzor
TCP doesn't even address QoS or any sort of IP throttling. It's simply an error/flow control layer that is added onto IP.
[/B]

Error control, flow control, and congestion control.

TCP congestion control is invoked whenever packets get dropped -- and packets always get dropped in the presence of TCP because TCP increases its packet rate until packets get dropped.

Yes, of course TCP doesn't have any *explicit* per-flow sharing of bandwidth, but the congestion control algorithm results in an implicit equitably sharing of bandwidth (or, more precisely, of packets, which is why using 1460 byte payloads is faster than using 536 byte payloads).

Yes, congestion is part of it. If I remember correcty there are a few different components to this which were added to the original TCP spec (ie, it was a later addition, I could be wrong though).

Anyway, whether not it addresses congestion, whether or not there _is_ congestion, and independent of any sliding window mechanics that deal with said congestion, I still maintain that downloading two files from the same location will <b>not</b> result in 100% more throughput.

Originally posted by cperciva
Originally posted by nopzor
TCP doesn't even address QoS or any sort of IP throttling. It's simply an error/flow control layer that is added onto IP.


Error control, flow control, and congestion control.

TCP congestion control is invoked whenever packets get dropped -- and packets always get dropped in the presence of TCP because TCP increases its packet rate until packets get dropped.

Yes, of course TCP doesn't have any *explicit* per-flow sharing of bandwidth, but the congestion control algorithm results in an implicit equitably sharing of bandwidth (or, more precisely, of packets, which is why using 1460 byte payloads is faster than using 536 byte payloads). [/B]

Yes, congestion is part of it. If I remember correcty there are a few different components to this which were added to the original TCP spec (ie, it was a later addition, I could be wrong though).

Congestion control was in the original definition of TCP, but there were several elements (eg, retransmission timeouts) which were either left unstated or merely recommended; while there have been additions made over the years (eg, large windows) the fundamental mechanics have not changed.


Anyway, whether not it addresses congestion, whether or not there _is_ congestion, and independent of any sliding window mechanics that deal with said congestion, I still maintain that downloading two files from the same location will not result in 100% more throughput.

No, not 100% more throughput. But when there is a single bottleneck in the middle of the connection which is shared by many different flows, it will give "close to" 100% more throughput. ("close to" meaning 2n/(n+1) times as much throughput where n is the original number of TCP or TCP-like flows operating at maximal bandwidth, weighted by the inverse round trip time).

To illustrate, from the server I mentioned above at skynetweb, I get (right now) 5850 kbps with a single connection but 5900 kbps by using two simultaneous connections -- evidently the bottleneck here isn't being shared with other machines (or if other flows are sharing the bottleneck they are between machines more than 4.5ms apart). On the other hand, from the server I mentioned above at rackspace, I get 1640 kbps with a single connection, and a total of 2750 kbps by using two connections -- the bottleneck is being shared with several other machines.

150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 15.7 secs (5.3e+02 Kbytes/sec)

my server's at catalog.com

--
Alan "Dexter" Barber
Project Eternity - Get involved!
http://www.advanced-basic.com/project_eternity/

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 2.37 secs (3.5e+03 Kbytes/sec)
ftp>

That's close to 30Mbit!!

That's insane. But then again, check out these ping times.

[root@neuromancer /root]# ping -c 10 ftp.uu.net
[snip]
--- ftp.uu.net ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 6.2/6.4/6.8 ms

I am hosted on a RaQ4i from Rackshack.

150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 23.6 secs (3.5e+02 Kbytes/sec)

Not the best compared to others posts, but it keeps me happy :)

Regards,

Mike

Originally posted by nopzor
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 2.37 secs (3.5e+03 Kbytes/sec)
ftp>

That's close to 30Mbit!!

That's insane. But then again, check out these ping times.

[root@neuromancer /root]# ping -c 10 ftp.uu.net
[snip]
--- ftp.uu.net ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 6.2/6.4/6.8 ms


is that from your network?

Originally posted by teck
is that from your network? [/B]

Yup, it is. I'll leave out the gory details about network capactiy since that might border on advertising.

I will however talk about ports and switches.

(server that the ftp results are from is on a 100Mbit port, but for full disclosure I'll mention that all dedicated servers have a 10Mbit port unless you specifically request a 100Mbit port or can commit to 5Mbit).

A few months ago I saw a sustained download along the lines of 96Mbit (on a 1000Mbit port).

(btw, you won't neccesarily see this kind of througput on the lower end Cisco 2924 (maybe even the higher end 6000s eries) Catalyst switches. The backplane just doesn't cut it. I'd recommend Extreme Networks, they completely blow Cisco out of the water)

Cheers,

Raj Dutt

why are we discussing downstream (from the point of view of your server) bursty bandwidth, when most webservers are really a lot more interested in the upstream bandwidth? Most hosts probably have symmetric uplinks.

results may also be influenced by the time it is conducted and by variations in the network during those times (but of course).

What is the best way to test how burstable your server is for upstream transfer? I have two servers, so it's actually OK with me to test the upstream transfer burstability for my two servers.. how about others?

cheers,
:beer:

Dialtone:

12:36:17 (407.71 KB/s) - `uumap.tar.Z' saved [8520221]

My results from from a server at Verio:

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,154,229)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
100% |**********************************************************************| 8320 KB 00:00 ETA
226 Transfer complete.
8520221 bytes received in 2.44 seconds (3.33 MB/s)


My results from a dedicated RAQ at Tera-Byte:

Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 33.8 secs (2.5e+02 Kbytes/sec)


My results from a dedicated RAQ at Cobaltracks.com:

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 242 secs (34 Kbytes/sec)


-Mike

hispeed.com

madhosts.com server
8520221 bytes received in 38.6 secs (2.2e+02 Kbytes/sec)

dblegacy.com server
8520221 bytes received in 25.1 secs (3.3e+02 Kbytes/sec)

madhosts.net server
8520221 bytes received in 31.4 secs (2.6e+02 Kbytes/sec)

bear in mind all three servers are alrady doing 1-2mbs in traffic

............

ROFL @ cobaltracks.com and that 34

Yes... 34 KB/s -> my cable modem can do better than that! :D
So... why are you still with cobaltrack.com? Just curious... I will be complaining a lot if I get that kind of connectivity... :)

cheers,
:beer:

Take this for what its worth, since we are on the UUNET backbone, and one city away from the FTP Server:


ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 4.11 secs (18.3e+02 Kbytes/sec)


Pings:

PING ftp.uu.net (192.48.96.9): 56 data bytes
64 bytes from 192.48.96.9: icmp_seq=0 ttl=247 time=3.7 ms
64 bytes from 192.48.96.9: icmp_seq=1 ttl=247 time=3.6 ms
64 bytes from 192.48.96.9: icmp_seq=2 ttl=247 time=3.5 ms
64 bytes from 192.48.96.9: icmp_seq=3 ttl=247 time=3.4 ms
64 bytes from 192.48.96.9: icmp_seq=4 ttl=247 time=3.6 ms
64 bytes from 192.48.96.9: icmp_seq=5 ttl=247 time=3.7 ms
64 bytes from 192.48.96.9: icmp_seq=6 ttl=247 time=3.7 ms
64 bytes from 192.48.96.9: icmp_seq=7 ttl=247 time=3.5 ms
64 bytes from 192.48.96.9: icmp_seq=8 ttl=247 time=3.5 ms

Does anyone have any other public FTP servers to test from? Those kind of statistics would be nice to be able to supply to clients.

Originally posted by dektong
Yes... 34 KB/s -> my cable modem can do better than that! :D
So... why are you still with cobaltrack.com? Just curious... I will be complaining a lot if I get that kind of connectivity... :)


1. The Cobaltracks server is used as a backup nameserver.

2. It's a spare RAQ that can be used temporary if one of the others fail. I do not keep any live sites on it.

3. I also use it to test scripts and backup some files.

-Mike

Ok everyone... wondering how things are since Site5 moved to NAC?

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 3.52 secs (2.4e+03 Kbytes/sec)

Needless to say, we've been very pleased with the connectivity. ;)

Regards,
Matt
mlightner@site5.com

sh1t thats fast

Hm... there is another one that is about 50% faster (Aroudn 3.5 MB/s) ... now, that's fast! :D

cheers,
:beer:

Originally posted by dektong
Hm... there is another one that is about 50% faster (Aroudn 3.5 MB/s) ... now, that's fast! :D
That was the server located at Verio. They have a huge, national network. Very fast too!

But NAC's not bad considering it's just a regional NOC. :)

Regards,
Matt
mlightner@site5.com

VDI
-----------------------------------------
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 2.16 secs (3.8e+03 Kbytes/sec)
ftp>


VDI believe it or not. http://onegreatserver.com/sys/
But this is midnight.

again
8520221 bytes received in 2.12 secs (3.9e+03 Kbytes/sec)

------------------------------

Alabanza
-------------------------------------------
WOW I really can't believe this one.

3 times
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 1.54 secs (5.4e+03 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 1.57 secs (5.3e+03 Kbytes/sec)


Go figure.....

OK... your server at VDI has already impressed me. I only can get around 1900 KB - 2000KB/s, same thing... around midnight..

Then... your server at alabanza really really got my attention! Wow! that is what I call fast! around 43 Mbps! :D

cheers,
:beer:

OK... your server at VDI has already impressed me. I only can get around 1900 KB - 2000KB/s, same thing... around midnight..

Then... your server at alabanza really really got my attention! Wow! that is what I call fast! around 40 Mbps! :D

cheers,
:beer:

I guess you mean you are on VDI? Maybe not but if you are do me a favor. I have been noticing a every 16 minute packet loss problem at VDI. I run ping plotter all day and every 15 minutes their network dies for about 10 seconds.This is driving me crazy.

Go in your VDI box (if you are on VDI) maybe you aren't. Any how ping that ftp.uu.net. Watch it and about every 16 minutes you will see it stop and then 10 seconds later it will start again. Well when it starts again look at the ping sec numbers. That network is fast but all day long every 8 or 16 minutes the damn thing shuts off. All the servers do it , even the switch IPs so it is a network issue. I am wondering if someone is runing a cron job from server to server that is doing it internal.???

Hell if you arent on VDI then how about from where (anyone please try this) any of you are open a prompt and ping webhostingtalk.com for me. Let it run. Watch what happens ever 16 minutes. I have a graph of it if anyone wants to see. 2 days of this crap. That network smokes until you hit the 16 minute cycle. Only today it was 8 minutes apart and the timeouts were about 30 seconds. Maybe their new router has gone into labor?

rpmws, yes there is definitely something odd there. Over the past 15 minutes I've seen about 0.5% packet loss except for a 40 second interval around 22:08 PDT where there was about 75% packet loss. Interestingly I see none of the normal signatures associated with packet loss caused by high load, so I'd guess it is a software problem somewhere.

Look at this http://www.webhostingtalk.com/showthread.php?threadid=7872

I just posted it.... as a matter of fact about 1:25am we just went through another. ;-(

well someone just suggested to me that it is their "ARP"
I found this article http://www.unixinsider.com/swol-05-1997/swol-05-sysadmin.html

:-(

RaQ at RackShack:


ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 21.3 secs (3.9e+02 Kbytes/sec)


Server at DTWebWorks:


ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 31.1 secs (2.7e+02 Kbytes/sec)

I am interested on the dtwebworks.com transfer rate... Could you try to do this at different times? Does the transfer rate fluctuate? 270KB/s is OK but not really great, especially since they guarantee no more than 50% capacity for their connectivity...

let me know

cheer,
:beer:

Yeah, I'm definitely going to check it out again around 3pm and 7pm. I'll post my results here.

VDI .... 1:55PM

3 times:
----------------------------------------
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 6.11 secs (1.4e+03 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 5.17 secs (1.6e+03 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 4.95 secs (1.7e+03 Kbytes/sec)
ftp>

alabanza this time
-----------------------------------------------------

3 times: 2PM
-------------------------------------------
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 7.39 secs (1.1e+03 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 7.45 secs (1.1e+03 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 8.09 secs (1e+03 Kbytes/sec)
ftp>

I have to tell you guys, looking through these results I have to say that at least to that FTP uu.net address that VDI has the biggest burst speed. If they can get their packet loss fixed with this new upgrade they may just be the place to be as far as network speed.

My Alabanza box was screaming last night but today when it counts my VDI box beats it pretty bad.

Does anyone else here have results for VDI or Alabanza based machines or is it just me?

yeah, your alabanza server was on drugs last night.

They must of some how accidentally connected it to the "fast" network they have been hiding from most from us during the rest of the day, huh? But you know I have noticed even today, they are actually letting packets through. Actually is't pretty darn fast. Maybe some big client they had pulled out and left a bandwidth hole for me to fill.

Here are some more results from DTWebWorks:


ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 39.4 secs (2.1e+02 Kbytes/sec)


The results from RackShack are pretty much the same.

VDI ...3 times at 5:50PM EST Apr3,2001
---------------------------------------------------------
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 2.73 secs (3.1e+03 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 4.01 secs (2.1e+03 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 3.08 secs (2.7e+03 Kbytes/sec)
ftp>

Alabanza again 5:55PM EST Apr3, 2001
-------------------------------------------------------
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 6.07 secs (1.4e+03 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 5.2 secs (1.6e+03 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 3.62 secs (2.3e+03 Kbytes/sec)
ftp>


Are you sick yet?

I'm 3ms ping away... soooo

Try #1:
8520221 bytes received in 2.51 seconds (3.23 MB/s)

Try #2:
8520221 bytes received in 2.79 seconds (2.91 MB/s)

Try #3:
8520221 bytes received in 2.69 seconds (3.02 MB/s)

Not bad I'd say. :D

rpmws
QUOTE

"I have to tell you guys, looking through these results I have to say that at least to that FTP uu.net address that VDI has the biggest burst speed. If they can get their packet loss fixed with this new upgrade they may just be the place to be as far as network speed. "



We have been studying the 16th Min packet drop and working with Cisco. The Cause is basicly too many arps in 1 subnet, and arp table gets heavy. We were told the IOS upgrade "we are planning to do Friday" will remedy this.

also we are subnetting all new clients and moving old clients to thier own subnets. Cisco says this will speed things up even more.

Once we get the router upgrade completed on friday after midnight. another improved speed.

April 24th "another 155 MBPS will be added" I really will look forward to all of you testing the network and tell me how good or bad it is. We spent the money and started the process.

Everything and all upgrades should be completed by may 1st.

Sounds great Bill !! I look forward to it...

-----------------------------------------------
Getting back to the FTP results I had this morning on my VDI box I figured I would include a ping set the ftp.uu.net site also. Some others have also included PING results indicating it may have some influence on throughput results. It just may. Here is what I got this morning at 10:05 AM Wed , April 4,2001

My results:
--------------------------------------------------------
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 2.16 secs (3.8e+03 Kbytes/sec)
ftp>
--------------------------------------------------------
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=8 ttl=246 time=22.031 msec
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=9 ttl=246 time=18.031 msec
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=10 ttl=246 time=11.484 msec
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=11 ttl=246 time=17.276 msec
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=12 ttl=246 time=14.241 msec
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=13 ttl=246 time=12.137 msec
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=14 ttl=246 time=14.014 msec
--------------------------------------------------------

This is fun!!! Now I need to get back to work. :-)

It's now 10:35am EST and I am only getting about 1.4-1.7 MB/s transfer rate (just about half what you are getting). This is also from my box at interserver/VDI. Ping times are about the same, so why is my rate just about half?

cheers,
:beer:

Not sure, maybe you hit one of those every 16 minute 5 second speed bumps.
10:45 AM
--------------------------------------------------------
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 3.78 secs (2.2e+03 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 3.16 secs (2.6e+03 Kbytes/sec)
ftp>


A little slower than earlier. It may be that my machine in only doing about 10GB per month right now.

I have got a dedicated server at Pair Networks. It seems they are really fast :)


ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,227,95)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
100% |**************************************************| 8320 KB 00:00 ETA
226 Transfer complete.
8520221 bytes received in 1.73 seconds (4.69 MB/s)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,227,97)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
100% |**************************************************| 8320 KB 00:00 ETA
226 Transfer complete.
8520221 bytes received in 1.86 seconds (4.37 MB/s)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,227,99)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
100% |**************************************************| 8320 KB 00:00 ETA
226 Transfer complete.
8520221 bytes received in 1.89 seconds (4.29 MB/s)

That's really impressive!!! wow...

Update for weinbar connectivity.
I was able to burst (download) to 2200KB/s at one point (around 17.6 Mbps). Typical value was around 10 Mbps... Still waiting for my server to burst to 25 Mbps as I was told they were able to.

cheers,
:beer:

Well, I am also most happy with these results.

When I visit this forum I see a lot of postings from people who pay $99 or $199 per month for a dedicated server. My dedicated server (PIII,733Mhz,384 Mb) costs $ 399 per month but luckily that translates into a better performance.

I'm still getting about 350 Kbytes/sec on my Weinbar server in a single FTP session to download uumap.tar.Z. But if I have 10 separate FTP sessions with each of them downloading that file, they get an average of 210 Kbytes/sec...multiply by 10 for a total of 2100 Kbytes/sec.

I think I've used up my monthly data transfer quota with this testing! :D

Do you mean you opened 10 FTP sessions simultaneously? How do you do that? I tested on one of my server (it always gave me slower rate by the way, compared to my other server). I was able to burst to 690 KB/s (around 5.6 Mbps).

cheers,
:beer:

Originally posted by dektong
Do you mean you opened 10 FTP sessions simultaneously? How do you do that?

10 shell logins and some repetitive typing. :)

and how do you make it simultaneous, all executed at the same time?

cheers,
:beer:

I logged in my server in 10 separate sessions, logged in to the FTP site with each of those sessions, and typed "get uumap.tar.Z N" (where N = 1 to 10) in each of those FTP sessions. Then I quickly went from window to window pressing ENTER in each one to start all of the download sessions.

So they weren't *exactly* all at the same time... But since the total download time was about 30 seconds, the 2 seconds difference between the first download session and the last download session wasn't a big deal.

Originally posted by Phiberop
I am hosted on a RaQ4i from Rackshack.

8520221 bytes received in 23.6 secs (3.5e+02 Kbytes/sec)


Originally posted by Justin S
RaQ at RackShack:

8520221 bytes received in 21.3 secs (3.9e+02 Kbytes/sec)


Just got my first RaQ 4i at RackShack yesterday:

8520221 bytes received in 16 secs (5.2e+02 Kbytes/sec)
[admin admin]$ date
Wed Apr 11 04:10:03 CDT 2001

later that day:

8520221 bytes received in 18 secs (4.6e+02 Kbytes/sec)
[admin admin]$ date
Wed Apr 11 08:55:08 CDT 2001

So with Rackshack we all getting 350-520 Kbytes/sec, which is approx. 2.8-4.2 Mbits/sec

[Edited by dabystru on 04-11-2001 at 09:58 AM]

dektong -- I found that your UU net test sucked for me at Weinbar... I got only 220K...

I have a OUTDATED list of files I have used in the past to test my 8Mpbs DSL lines...
http://www.roundsparrow.com/Seattle/xDSL/DL/
NOTE THE LIST IS OLD and already the first few files on the list are not working.

Anyway, the 4th file on the list -- ftp.mozilla.org got me over 520K/second

The 11th file on the list -- www.cisco.com using http, I got over 680K/second...

your UUnet test file was always under 220K...

This was at 4:00pm to 4:30pm PDT on Friday.

humm.. VDI

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 3.12 secs (2.7e+03 Kbytes/sec)

------
More to come

(2.7e+03 Kbytes/sec)

is that in the 270's ??

hundreds??
Or does that mean 2.7 megs

Cause I dont see how you can d/l a file 8mb in size (i beleive) at 270k/sec in 3.2 secs

2.7e+03 Kbyte/sec = 2700 KB/s ... that's pretty darn fast (hence, it took only about 3.2 seconds to download)!

cheers,
:beer:

dektong -- do you see the improvements on the Mozilla and Cisco downloads that I see? Thanks.

StephenRS, the ftp.uu.net have been giving me constantly about 420KB/s (I have two servers there, the one somehow much slower than the other, this is the slower one... the faster one I can't try since it's my client's now. I don't want to login just to try the speed, do I? :) ).

So... with the same server, I got ~ 630 KB/s for the mozilla file and ~490KB/s for the cisco file (gee... I stopped after 75MB! :) ). Anyway, this was around 5:00-5:30AM EST.

I will try to redo the test with my other server, supposed to be faster but since I use my own switch (10mbps switch Cisco Catalyst 3100), it will no longer go above 10mbps... :(

BTW, since you are still wondering, ftp.uu.net is located at Fairfax, VA, I believe. You can check the geographical location with visualroute (http://www.visualware.com/visualroute/livedemo.html) and choose the starting point of your traceroute in London, Hong Kong, Madrid, Poland, etc. I find this little software is quite useful sometimes....

cheers,
:beer:

I just think the paths to that uunet site are congested at times.... as my download from Mozilla beats your download from Mozilla and I'm on a very fast machine with a good network card (Intel Pro).... so it obviously isn't the Weinbar LAN...

I just tried again at 1:10pm PDT... I got 200K again from UUnet, and 710K from Cisco!

http://www.roundsparrow.com/Seattle/xDSL/DL/

Originally posted by StephenRS
I just think the paths to that uunet site are congested at times....

Unlikely, since I have done this test at random (really, anytime I feel like it) and I always get around 400-420KB/s with my slower NIC. Yet the same server (with 3C905b NIC) on interserver always get me around 1700-2000KB/s, everytime....


as my download from Mozilla beats your download from Mozilla and I'm on a very fast machine with a good network card (Intel Pro).... so it obviously isn't the Weinbar LAN...

Though I doubt it's weinbar lan (hey, we are in the same network, just different switch), I should say ... hold on, I only do your test once! :) BTW, I won over you with the mozilla test (just did it once).

Redid the test, mozilla still gave me ~630KB/s, cisco still gave me ~490KB/s, and uunet still gave me ~420KB/s

what is your server connected too? 10 mbps or 100 mbps switch?

cheers,
:beer:

My adapter reports 100Mbps Full Duplex.

I actually have a 2nd adapter (unconnected) in the box too that I could try... it is a LinkSys LNE100TX -- which is an excellent clone of the Digital "Tulip" chipset ... very good for servers (and dirt cheap)...

I'm not that worried, just odd why I never get over 220K to ftp.uu.net ...

Maybe your operating system (TCP/IP stack) is tuned to allow latency better? All your timings seem to favor the far-away sites but not the close ones? You can't match my Mozilla and Cisco downloads... you haven't been able to get near my 710K figure.

at 2:14pm PDT I did a ping of ftp.uu.net and got 70ms, I get 20ms when pinging www.cisco.com!

I know there are settings I have to weak on my 8Mbps (yes 800Kbytes/second) DSL that I have at my home... especially for high latency sites.

I have my server tuned for smaller network requests, 10K average, not for downloads... I have a very high traffic and time-sensitive site going on ( www.esnipe.com )

Just did another Cisco test at 2:22pm PDT -- got 709K on 12MB average (before I canceled).... uunet I got average of 205K on entire file (8MB).

On the uunet download, i observed the traffic spead up and slowed down at times... like there is a busy link or server... whereas the Cisco one is very steady...

Anyone tried this using Version12.net ? As they are in a UUNET noc it would be pretty interesting lol :)

-BW

I'm hosted at www.dtwebworks.com , and it gives 3.1e+02 kb/sec (so around 310kb/sec) ... the ping is around 80

Not too bad, altough more interresting would be the upstream speed for the server than the downstream, since having visitors is only upstream

my upstream rate is similar to my downstream rate (why wouldn't they?)

cheers,
:beer:

dektong -- it is my experience that most "large pipes" are symetrical....

And ISP's are typically in the business of pushing content, not accepting it... so it isn't unheard of to see great performance INTO your server, but problems going OUT of your server...

Last night I had to transfer a 90MB file from DedicatedHosting.com to Weinbar.com ... it sucked! I get better transfer from my own PC to Weinbar :) And this was at 1AM PDT.

This is from BurstNET's new Scranton, PA data center via Sprint DS-3 connectivity:

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 8.73 secs (9.5e+02 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 8.88 secs (9.4e+02 Kbytes/sec)
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 8.74 secs (9.5e+02 Kbytes/sec)

Mark Vockler
Aletia Hosting

This is what i got

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 21.7 secs (3.8e+02 Kbytes/sec)

I am on rackspace

How good or bad is it ?

My Version 12 site results
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 11.6 secs (7.2e+02 Kbytes/sec)

VDI - Ventures Online
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 4.49 secs (1.9e+03 Kbytes/sec)

Thats what mine at version 12 gets too :D
It varies between 9 and 11 seconds :)

:stickout

8520221 bytes received in 23.6 secs (3.5e+02 Kbytes/sec)
8520221 bytes received in 21.3 secs (3.9e+02 Kbytes/sec)
8520221 bytes received in 16 secs (5.2e+02 Kbytes/sec)
8520221 bytes received in 18 secs (4.6e+02 Kbytes/sec)Interesting, I just tried to run several FTP sessions with RackShack by method suggested here and get no decline of speed! I tried 1, 2, 4 and 8 FTP sessions simultaneously and constantly got 480-520 Kbytes/sec for each session, which gives us about 4 Mbytes/sec for 8 simultaneous sessions. Anyone to guess why it does not burst to 4 Mbytes/sec with one session?

It could be that the FTP is set so it will only allow 500kb/user. A lot of people do that to avoid one person getting 5mb/sec and the other 20kb/sec. This way they can have 10 people downloading with 500kb/sec which is a very good speed.

Originally posted by zolbian
It could be that the FTP is set so it will only allow 500kb/userHmm... It should not be ftp.uu.net problem - some people were able to get much higher speeds. So, is it my FTP client limitation? I never changed any FTP settings. Do you think there is some FTP limitation preset with a default load of every new Cobalt RaQ 4i? Would you advice where to change this setting?

Burstnet owned them.. However, I'm sure Rackspace has more bandwidth.

[deleted]

from Cobaltrack.com (definate improvement over what was posted previously for them).

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 36.4 secs (2.3e+02 Kbytes/sec)

Thats 1.9 Mbits/s

Just this morning from one of our servers @ NAC.

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 2.21 secs (3.8e+03 Kbytes/sec)

About 3.71 Mbytes/sec. :D

Best Regards,
Matt Lightner
mlightner@site5.com

*****:

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 14.5 secs (5.8e+02 Kbytes/sec)

Serverhost (Columbus):

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,175,102)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 16.8 secs (4.9e+02 Kbytes/sec)

Serverhost (Greenville):

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 70.1 secs (1.2e+02 Kbytes/sec)

Weinbar:

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 25.5 secs (3.3e+02 Kbytes/sec)

Charter@Work (@Home):

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,175,120)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 34.1 secs (2.4e+02 Kbytes/sec)

Originally posted by Site5-Matt
About 3.71 Mbytes/sec. :D


Really??? As much as I want to believe it, I will have to say I am really skeptical about that, Matt.... :D I won't believe it until I try it myself :) The last time I tried on your server, it bursted only to 400 Kb/s. And my server with you can only burst to 690 Kb/s (used to be able to burst to 2100 Kb/s when I was with interserver).... So Matt, why can't my server burst that much? :( :(

cheers,
:beer:

Maybe he means BITS instead of BYTES.. There's a factor of eight involved there... :)

he means bytes, not bits. look at the .GZ file and you can see it's around 8 megabytes. if you look at his transfer rate, it took roughly 2.x seconds. that concludes it's around 3.x megabytes per second. i'm surpised you questioned that jeff.

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 2.52 secs (3.3e+03 Kbytes/sec)


From one of my servers. Umm.... Good...

Hey, matt is looks like we are leading the pack with the fastest download speeds. :)

Originally posted by teck
he means bytes, not bits. look at the .GZ file and you can see it's around 8 megabytes. if you look at his transfer rate, it took roughly 2.x seconds. that concludes it's around 3.x megabytes per second. i'm surpised you questioned that jeff.

I mis-read it - oops. Thought it said 22.1 instead of 2.21... :) Sorry about that.

Originally posted by dektong


Really??? As much as I want to believe it, I will have to say I am really skeptical about that, Matt.... :D I won't believe it until I try it myself :) The last time I tried on your server, it bursted only to 400 Kb/s. And my server with you can only burst to 690 Kb/s (used to be able to burst to 2100 Kb/s when I was with interserver).... So Matt, why can't my server burst that much? :( :(

cheers,
:beer:
Dektong,

I'm extremely dissapointed to hear that you think (or are even implying) I'm lying about that. I would hope you would have a bit more faith in me by now. ICQ me and I will give you a login to the server... that way you can see it with your own eyes. Honestly, I have better things to do with my time than to forge UUnet download speeds. :(

Best Regards,
Matt Lightner
mlightner@site5.com

To whom it may concern...

The results I posted above were from a linux 2.4.4 system. Strangely enough, different OS's seem to get different download speeds (even if they are connected to the same switch). For example, I tried the same test on two OpenBSD systems and they returned results of about 7 seconds. Additionally, I tried it on two servers running linux 2.2.x (one of which was dektong's), and they returned results of about 12 seconds each; quite a variance IMO. These results are leading me to question the validity of this testing method (as if I wasn't questioning it before). Anyone who is receiveing less-than-stellar results on this particular test should take into consideration the OS being used on the server.

Just a thought. If anyone else has multiple OS's running behind the same switch and can confirm this, that would be great!

Best Regards,
Matt Lightner
mlightner@site5.com

my workstation at school:

8520221 bytes received in 7.2 seconds (1150.71 Kbytes/s)

my server at vo(verio):

8520221 bytes received in 30.7 secs (2.7e+02 Kbytes/sec)

account on server at nac.net:

8520221 bytes received in 2.5 seconds (3.4e+03 Kbytes/s)

Conclusion: Matt is not lieing since I got just about the same speeds as he did. I wish my server at verio is faster but what can I do? According to vo, it should be faster in a few weeks as 2 hops will be taken out of the loop.

I have tried my solaris 2.6 system waiting to try 2.7 and I have tried my linux 2.2 and linux 2.4 servers.

Out of Solaris 2.6, linux 2.2, and linux 2.4

The 2.4 kernels IP Stack is far surperior to that of solaris 2.6 and linux 2.2. They download speed is roughly 2.x second while linxu 2.2 is roughly 14.x second fors me and solaris around 20.x seconds.

Also to clarify we don't even have a direct connection to UUNet, we are once removed via exodus or Internap. And we are beating those companies with direct connections and national backbones.

Gotta love it...:)

Well, the server I used at my school is running Solaris:

SunOS nothing 5.6 Generic_105181-26 sun4u sparc SUNW,Ultra-Enterprise

It doesn't really matter to me since I really don't see speeds faster than what I posted so I can't compare it to any other OS behind the network.

Sharp Web Innovations

8520221 bytes received in 2.36 secs (3.5e+03 Kbytes/sec)

Sharpwebinnovations.com/ Nac.net Server Room

Originally posted by Site5-Matt

Dektong,

I'm extremely dissapointed to hear that you think (or are even implying) I'm lying about that.


Hmm.... first of all, sorry if I was skeptical about the result and qas questioning the result. Again, my apology Matt...


I would hope you would have a bit more faith in me by now. ICQ me and I will give you a login to the server...


Again my apology. I did not mean not to believe you...r eally, but when you said you could burst to that speed, i was so excited and tried it out and yet I could only got to 690 Kb/s... and I was disappointed and that might explain why I said those things. Again, my apology.

cheers,
:beer:

Thanks for the apology dektong.

If you upgrade your kernel to 2.4, you should have similar speed results. In this case, the problem is not the connection, but the OS. :)

Hope that helps.

Best Regards,
Matt Lightner
mlightner@site5.com

Originally posted by Site5-Matt
The results I posted above were from a linux 2.4.4 system. Strangely enough, different OS's seem to get different download speeds (even if they are connected to the same switch). For example, I tried the same test on two OpenBSD systems and they returned results of about 7 seconds. Additionally, I tried it on two servers running linux 2.2.x (one of which was dektong's), and they returned results of about 12 seconds each; quite a variance IMO. These results are leading me to question the validity of this testing method (as if I wasn't questioning it before). Anyone who is receiveing less-than-stellar results on this particular test should take into consideration the OS being used on the server.


Matt, you seem to forget something. The fact that I got the download rate of about 2100 KB/s when my server was with VDI... Now, what has changed in my server since the move? Nothing, right? So this itself should clearly tells you that it has nothing to do with server OS...

Now here is my theory.... :D
The download rate might very well depends on which port your server is connected to the switch or which part of the network your server is connected to. If I am not mistaken there was a discussion here a while ago about this and the fact that different switch port may give different performance (some ports may not function as well as the others?). Can this be the possibility?

cheers,
:beer:

Originally posted by Site5-Matt
If you upgrade your kernel to 2.4, you should have similar speed results. In this case, the problem is not the connection, but the OS. :)


Hmm... I should probably say the OS kernel might have an impact on this, but again it might not be the only factor (see my reply before). Which port your server is connected to might also be a factor (cmiiw). But for sure I would be more than willing to upgrade my OS kernel.... :D

cheers,
:beer:

Originally posted by jayglate
The 2.4 kernels IP Stack is far surperior to that of solaris 2.6 and linux 2.2. They download speed is roughly 2.x second while linxu 2.2 is roughly 14.x second fors me and solaris around 20.x seconds.


Jay, nice to hear that! I need to know also, what else is different (except for the OS kernel) between the two servers? Are they connected to the same switch? If they are, what would the result be if you switch the switch ports they are connected to?


Also to clarify we don't even have a direct connection to UUNet, we are once removed via exodus or Internap. And we are beating those companies with direct connections and national backbones.

Gotta love it...:)

Am I the only one at NAC that can't burst beyond 700KB/s? :D Gotta Love it? Woa... Of course!!! why not? :D

cheers,
:beer:

Originally posted by dektong


Hmm... I should probably say the OS kernel might have an impact on this, but again it might not be the only factor (see my reply before). Which port your server is connected to might also be a factor (cmiiw). But for sure I would be more than willing to upgrade my OS kernel.... :D

cheers,
:beer:
Interesting, because others actually confirmed the kernel OS made a difference.

Only one way to find out... you would be an excellent test case. ;)

Best Regards,
Matt Lightner
mlightner@site5.com

this thread is beginning to border on ridiculous :)

the speed that your going to see with your servers with different providers is dependent on soooooo many things.

factors include

time of day
load on uunet
peering point congestion
tcp stack (OS) (although this doesn't make as much as a difference as some have implied).
load on your server
efficiency of client software
dumb luck.

not saying that this isn't fun to discuss, but people should realize that this is really really not a good (or accurate) way to compare providers.

rd.

Originally posted by nopzor
this thread is beginning to border on ridiculous :)

not saying that this isn't fun to discuss, but people should realize that this is really really not a good (or accurate) way to compare providers.
Glad I'm not the only one who realizes this. ;)

If anything, this measures how well you're connected to UUNet. I hope nobody has based any purchases on these statistics alone. It's fun to test and see the different download speeds, however this is not an accurate way to judge a network's performance, IMHO.

Best Regards,
Matt Lightner
mlightner@site5.com

Hi Raj, long time not talking to you!! :)

Originally posted by nopzor
factors include

time of day


I have done the test at random time... Really random. I always get the same consistent download rate (the same with my other server at weinbar), so I guess time of day, though is really important, does not really affect the test result, not by a factor of 6 for sure :)


load on your server


I am pretty sure my server would have one of the lowest load here and yet my server does not give me the highest download rate... Here is my server load:
12:49am up 18 days, 8:16, 1 user, load average: 0.00, 0.01, 0.00
93 processes: 92 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.1% user, 0.9% system, 0.0% nice, 98.8% idle

cheers,
:beer:

True, this does test your speed to UUNet and no other network, but as a very high percentage of internet traffic goes through UUNet then it is a useful test. Most people would agree that UUNet does not slow down very often and some of this test allows you to see how good your connection is and if there are slow networks along your route, it then allows you to run a traceroute to see which network is slow along your route.

~~~~~~~~~~~
time of day - this point can be discredited by using the averages of each of the results here from a single host

load on uunet - If UUNet is overloaded, god help us all!

peering point congestion - this is partially what the test is for

tcp stack (OS) (although this doesn't make as much as a difference as some have implied). - agreed

load on your server - hopefully tested whilst the server us under low/average load

efficiency of client software - everyone is using the same software - FTP or WGET, although varying OS's could change results

dumb luck. - agreed!

~~~~~~~~~~~

A high percentage of traffic does go through UUnet, but a lot of very good providers may not peer directly with UUnet. In addition, ftp.uu.net is just a single machine at a particular geographical location. In addition, UUnet can and does (pretty often actually) get overloaded.

I still make the argument that there are a lot of better ways to test out a network.

Originally posted by xtstrike
True, this does test your speed to UUNet and no other network, but as a very high percentage of internet traffic goes through UUNet then it is a useful test. Most people would agree that UUNet does not slow down very often and some of this test allows you to see how good your connection is and if there are slow networks along your route, it then allows you to run a traceroute to see which network is slow along your route.

~~~~~~~~~~~
time of day - this point can be discredited by using the averages of each of the results here from a single host

load on uunet - If UUNet is overloaded, god help us all!

peering point congestion - this is partially what the test is for

tcp stack (OS) (although this doesn't make as much as a difference as some have implied). - agreed

load on your server - hopefully tested whilst the server us under low/average load

efficiency of client software - everyone is using the same software - FTP or WGET, although varying OS's could change results

dumb luck. - agreed!

~~~~~~~~~~~

From our new dedicated at weinbar.com

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 23.2 secs (3.6e+02 Kbytes/sec)
ftp>

I guess these figures are not that good :-(

This is what I get at VDI .have all along, even through the slow days.

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 2.01 secs (4.1e+03 Kbytes/sec):)

Well, I am allready told that these tests are absolutly telling you nothing and getting a good figure doesn't garantee anything.

I will agree with that. For the most part it means nothing. However I will tell you this, I have a company that uses me as a host and they are on a T1 at their office. They can tell a difference in my Alabanza and VDI burst speeds as well as their racespace.com server. And their racespace.com server is 5 hops away from them while 17 form my VDI box. So my thoughts are with the trend going toward 2mb cable modems at home, and everyone using them to hit your server more and more, sooner or later a 500Kbit connection may seem weak to someone before it is all over with. The UUNET test is not worth anything unless you use it to compare servers in the same NOC I guess. The speed one gets is only as good as the slowest link along the way and with different links who knows??

We just tested it on our 4webspace raq3:

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 23.9 secs (3.5e+02 Kbytes/sec)

350 k for 99$ / month is quite great ;)

200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (
226 Transfer complete.
8520221 bytes received in 15.9 secs (5.2e+02 Kbytes/sec)

RackShack 12:50 AM Eastern time....

Originally posted by Domenico
Well, I am allready told that these tests are absolutly telling you nothing and getting a good figure doesn't garantee anything.

if it doesn't than ... getting a much lower figure will tell you a lot more things? :)

cheers,
:beer:

Originally posted by Site5-Matt

Interesting, because others actually confirmed the kernel OS made a difference.


Matt... I finally got about 1.6-2.2 MB/s (up to 17.6 Mbps) of burst rate from uunet ... I am happy :) But, it was with the same kernel, 2.2.14 .. haven't upgraded yet :)

Though the differences then and now do confuse me ... somehow I fell relaxed being able to burst to more thn 2 Mbps :) Did NAC recently add bandwiths/connectivitiy?

cheers,
:beer:

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 3.94 secs (2.1e+03 Kbytes/sec)


from VDI

Couldn't stay out of this one...Too much fun...

RAQ3 at DialtoneInternet:

150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 16.3 secs (5.1e+02 Kbytes/sec)

Home Mandrake 7.2 on CenturyTel(rural phone company) DSL:

150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 162 secs (51 Kbytes/sec)

Dektong, yes, we added another OC3,

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 1.9 seconds (4.3e+03 Kbytes/s)
ftp>

Nice, huh? :cool: :D

Is that from PWEBTECH kiwi?

NAC.net :)

SAME DIFFERENCE :D

Yep, huuuge difference :D

Sharp Web Innovations:
http://www.sharpwebinnovations.com

8520221 bytes received in 2.83 secs (2.9e+03 Kbytes/sec)

:D Nac , Need I say more?

I cant wait until i get my server with pegasus, only one problem.. im going to use up all my bandwidth just seeing how fast it can go :D

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 17.1 secs (4.9e+02 Kbytes/sec)


dialtone
from virtual account on one company that sells hosting in Croatia

4:27am up 169 days, 13:39, 1 user, load average: 0.95, 0.71, 0.55
131 processes: 124 sleeping, 1 running, 5 zombie, 1 stopped
CPU states: 11.1% user, 50.0% system, 0.0% nice, 38.8% idle
Mem: 322616K av, 319640K used, 2976K free, 344432K shrd, 116892K buff
Swap: 102808K av, 31508K used, 71300K free 111012K cached

8520221 bytes received in 11.6 secs (7.2e+02 Kbytes/sec)

Shared account at DataColo.(WizardsHosting)

These numbers don't mean anything, but it is amusing to check.


shared account with affordablehost.com:

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 16.3 secs (5.1e+02 Kbytes/sec)


linux box at home (AT&T Broadband cable modem):

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 46.8 secs (1.8e+02 Kbytes/sec)

I realize its probably a little late for this but:


8520221 bytes received in 17.52 seconds (474.92 KB/s)

This is from our hosting provider *in norway*.
So, considering its probably going halfways across
the world this is good :)

Dedicated at Fastservers.net
8520221 bytes received in 10.3 secs (8.1e+02 Kbytes/sec)

Just bored

1Ghz server @ Serverbeach.com

150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 16.1 secs (5.2e+02 Kbytes/sec)

Steve

Originally posted by dektong
OK people... this is really interesting.. if you have a dedicated server, let's have all the numbers here... Everybody who has posted, will you repost it again here? Everybody else is welcome (including those having shared/virtual accounts).

Note: please also tell us who is your NOC...

ftp to ftp.uu.net
login: anonymous
password: your email
try to download the file: uumap.tar.Z[/b] (8.5 Mbyte in size) - If you don't know how to do this: once you are logged in into ftp.uu.net, do "get uumap.tar.Z"
That's all... spit out the numbers now....

First server: colocated at Interserver.net
Download speed: 440 Kbyte/s (1pm EST) - 2000 Kbyte/s (~11:00pm EST). Burst anywhere from 3.5 Mbps - 16 Mbps.

Second server: colocated at weinbar.com
Donwload speed: has been very consistent at 380 KByte/s (any time). Burst to about 3 Mbps.

Well, I am pretty satisfied with these numbers.... Quite all right....

How about yours? (yea, please repost here... so that we can have a single page where we can share these fun info).
[/B]

Hey dektong, FHDave, which ever you prefer...:D

Would you mind posting the results for this "test" off of one of your servers located in InterNap?

Thanks. I'm just curious as to what the speeds are like...;)

My server

150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 15.4 secs (5.4e+02 Kbytes/sec)


very bad in my point :)


____

I did some others test and the top was 500 KB but it din't hold it...

and it was on a brazilian tucos... ( UOL ) that's the bigger ISP here

hostingsp - the idea is to tell us which data center you are downloading to.


nac.net
8520221 bytes received in 2.02 secs (4.1e+03 Kbytes/sec)

I tested three times, the results were exactly the same.


traceroute to ftp.uu.net (192.48.96.9), 30 hops max, 38 byte packets
1 209.123.73.1 (209.123.73.1) 0.479 ms 0.550 ms 0.531 ms
2 500.Serial2-5.GW7.NYC1.ALTER.NET (157.130.9.141) 1.873 ms 1.840 ms 1.736 ms
3 553.at-5-0-0.XR2.NYC1.ALTER.NET (152.63.25.86) 2.572 ms 2.276 ms 2.416 ms
4 0.so-1-1-0.XL2.NYC1.ALTER.NET (152.63.19.98) 2.306 ms 2.757 ms 3.416 ms
5 0.so-4-0-0.TL2.NYC9.ALTER.NET (152.63.23.129) 2.470 ms 0.so-1-0-0.TL2.NYC8.ALTER.NET (152.63.0.169) 3.290 ms 3.787 ms
6 0.so-5-0-0.TL2.DCA8.ALTER.NET (152.63.3.177) 8.248 ms 7.773 ms 8.112 ms
7 0.so-5-0-0.XL2.DCA8.ALTER.NET (152.63.35.250) 7.948 ms 8.848 ms 7.748 ms
8 188.at-2-0-0.CL2.IAD5.ALTER.NET (152.63.35.98) 8.929 ms 8.800 ms 9.150 ms
9 501.ATM7-0.GW3.IAD5.ALTER.NET (152.63.38.9) 10.153 ms 10.676 ms 10.156 ms
10 pos5-0.soesr1.ash.ops.us.uu.net (207.18.173.162) 10.234 ms 10.684 ms 9.108 ms
11 gig1-0.esr-b-10-9-1.ash.ops.us.uu.net (198.5.240.35) 8.004 ms 9.859 ms 8.136 ms
12 neo-ftp.uu.net (198.5.241.101) 9.512 ms 9.772 ms 9.433 ms

IT's not worh to say beacuse i'm goin to change dc in a few days..


but in the other point yours look pretty :)

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,130,196)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
100% |*************************************| 8320 KB 3.56 MB/s 00:00 ETA
226 Transfer complete.
8520221 bytes received in 00:02 (3.46 MB/s)
ftp>

Your Partner in Online Profitability:

http://www.Thruport.net

Oh, and incase you dont believe me, here is the full log:

Connected to ftp.uu.net.
220 FTP server ready.
Name (ftp.uu.net:esoriano): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password:
230-
230- Welcome to the UUNET archive.
230- A service of UUNET Technologies Inc, Falls Church, Virginia
230- For information about UUNET, call +1 703 206 5600, or see the files
230- in /uunet-info
230-
230- Please see http://www.us.uu.net/support/usepolicy/ for Acceptable
230- Use Policy
230-
230- Access is allowed all day. Current time is Sun Dec 8 07:26:37 2002 GMT.
230-
230- All transfers are logged with your host name and email address.
230- If you don't like this policy, disconnect now!
230-
230- If your FTP client crashes or hangs shortly after login, try using a
230- dash (-) as the first character of your password. This will turn off
230- the informational messages which may be confusing your ftp client.
230-
230-
230-Please read the file /info/README.ftp
230- it was last modified on Fri Jun 29 00:54:02 2001 - 527 days ago
230-Please read the file /info/README
230- it was last modified on Fri Jun 29 00:54:02 2001 - 527 days ago
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
500 'EPSV': command not understood.
227 Entering Passive Mode (192,48,96,9,109,207)
150 Opening ASCII mode data connection for /bin/ls.
total 18540
drwxr-sr-x 2 1 512 Jun 29 2001 .forward
-rw-r--r-- 1 11 0 Jun 29 2001 .hushlogin
-rw-r--r-- 1 100 59 Jun 29 2001 .kermrc
-rw-r--r-- 1 100 0 Jun 29 2001 .notar
d--x--x--x 3 1 512 Jun 29 2001 .tmppriv
drwxr-sr-x 13 1 512 Jun 29 2001 .vol
drwxr-sr-x 5 1 512 Jun 29 2001 admin
lrwxrwxrwx 1 0 1 Jun 29 2001 archive -> .
drwxr-sr-x 2 1 512 Jun 28 2001 bin
lrwxrwxrwx 1 0 23 Jun 29 2001 by-name.gz -> index/master/by-name.gz
lrwxrwxrwx 1 0 23 Jun 29 2001 by-time.gz -> index/master/by-time.gz
drwxr-xr-x 2 1 512 Jun 29 2001 cas
-rw-r--r-- 1 21 90112 Jun 29 2001 compress.tar
drwxr-sr-x 2 1 512 Jun 28 2001 dev
drwxr-sr-x 3 1 1024 Jun 28 2001 doc
drwxr-sr-x 6 1 512 Jun 28 2001 etc
lrwxrwxrwx 1 0 22 Jun 29 2001 faces -> published/usenix/faces
drwxr-sr-x 2 1 512 Jun 29 2001 government
drwxr-sr-x 2 1 1024 Jun 29 2001 graphics
-rw-r--r-- 1 21 798720 Jun 29 2001 gzip.tar
lrwxrwxrwx 1 0 17 Jun 29 2001 help -> info/archive-help
d--xr-xr-x 3 1 512 Sep 18 2001 home
drwxr-sr-x 20 21 1024 Jun 29 2001 index
drwxr-sr-x 2 1 512 Jun 29 2001 inet
drwxr-sr-x 4 1 512 Jun 29 2001 info
drwxr-sr-x 2 1 512 Jun 29 2001 kernel-bsdi
drwxr-sr-x 2 1 512 Jun 29 2001 languages
drwxr-sr-x 4 1 512 Jun 29 2001 library
drwxr-xr-x 2 1 512 Jun 28 2001 lost+found
lrwxrwxrwx 1 0 20 Jun 29 2001 ls-lR.Z -> index/master/ls-lR.Z
lrwxrwxrwx 1 0 21 Jun 29 2001 ls-lR.gz -> index/master/ls-lR.gz
lrwxrwxrwx 1 0 21 Jun 29 2001 ls-ltR.Z -> index/master/ls-ltR.Z
lrwxrwxrwx 1 0 22 Jun 29 2001 ls-ltR.gz -> index/master/ls-ltR.gz
-rw-r--r-- 1 21 6359 Dec 8 05:09 mm.status
drwxr-sr-x 4 1 512 Jun 29 2001 networking
drwxr-sr-x 2 1 512 Jun 29 2001 packages
d--x--s--x 41 1 1024 Oct 30 14:53 private
drwxr-sr-x 5 1 1024 Jun 28 2001 pub
drwxr-sr-x 2 1 1024 Jun 29 2001 published
lrwxrwxrwx 1 0 10 Jun 29 2001 sco-archive -> vendor/sco
drwxr-sr-x 9 1 512 Jun 29 2001 systems
drwxrwxrwt 3 21 2560 Dec 8 03:32 tmp
lrwxrwxrwx 1 0 17 Jun 29 2001 unix-today -> vendor/unix-today
lrwxrwxrwx 1 0 17 Jun 29 2001 unix-world -> vendor/unix-world
drwxr-sr-x 2 1 1024 Jun 29 2001 usenet
drwxr-sr-x 3 1 512 Jun 28 2001 usr
lrwxrwxrwx 1 0 16 Jun 29 2001 uumap -> networking/uumap
-rw-r--r-- 1 21 8520221 Jun 29 2001 uumap.tar.Z
lrwxrwxrwx 1 0 12 Jun 29 2001 uunet-info -> vendor/uunet
drwxr-sr-x 2 1 2048 Jun 29 2001 vendor
226 Transfer complete.
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,130,196)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
100% |*************************************| 8320 KB 3.56 MB/s 00:00 ETA
226 Transfer complete.
8520221 bytes received in 00:02 (3.46 MB/s)
ftp> ftp> get uumap.tar.Z
?Invalid command.
ftp> local: uumap.tar.Z remote: uumap.tar.Z
?Invalid command.
ftp> 227 Entering Passive Mode (192,48,96,9,130,196)
?Invalid command.
ftp> 150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
?Invalid command.
ftp> 100% |*************************************| 8320 KB 3.56 MB/s 00:00 ETA
?Invalid command.
ftp> 226 Transfer complete.
?Invalid command.
ftp> 8520221 bytes received in 00:02 (3.46 MB/s)

esoriano% traceroute www.uu.net
traceroute to www.uu.net (63.111.61.6), 30 hops max, 40 byte packets
1 it-router.thruport.com (65.199.9.129) 1.002 ms 0.422 ms 0.44 ms
2 it-gw-core-fe0-0-0-1-real-a.dca1.thruport.com (64.237.97.26) 1.027 ms 0.881 ms 0.916 ms
3 brdr2-gw1-fe4-0.dca1.thruport.com (64.237.97.9) 1.071 ms 0.886 ms 0.913 ms
4 brdr1-ipeer-fe3-0.dca1.thruport.com (64.237.97.1) 1.276 ms 1.093 ms 1.108 ms
5 500.serial1-10.gw10.tco1.alter.net (65.207.92.105) 2.033 ms 2.225 ms 2.313 ms
6 538.at-3-0-0.xr2.tco1.alter.net (152.63.38.162) 3.203 ms 2.238 ms 2.583 ms
7 192.at-0-3-0.xl2.dca8.alter.net (152.63.39.249) 3.119 ms 3.283 ms 3.053 ms
8 0.so-2-0-0.tl2.dca8.alter.net (152.63.35.249) 4.161 ms 3.933 ms 4.172 ms
9 0.so-7-0-0.tl2.atl5.alter.net (152.63.146.41) 19.222 ms 19.357 ms 20.444 ms
10 0.so-7-0-0.xl4.atl5.alter.net (152.63.85.194) 19.877 ms 19.293 ms 19.677 ms
11 192.at-5-0-0.wr2.atl5.alter.net (152.63.86.221) 20.866 ms 21.032 ms 19.242 ms
12 pos5-0.ur2.atl7.web.wcom.net (157.130.80.18) 19.326 ms 21.2 ms 20.544 ms
13 msfc-ds4-fn.atl7.web.uu.net (198.5.132.206) 20.891 ms 20.558 ms 21.273 ms

I spent 15 mins to do tests on several shared accounts, from VO, NAC, Internap, colo4dallas.

Here are the results:
--------------------------------------
Venturesonline/VO
9.87 secs (8.4e+02 Kbytes/sec),
12.3 secs (6.8e+02 Kbytes/sec),
10.3 secs (8.1e+02 Kbytes/sec),
14.8 secs (5.6e+02 Kbytes/sec),
11.8 secs (7e+02 Kbytes/sec),

load average: 0.33, 0.40, 0.44, 219 processes: 213 sleeping, 2 running, 4 zombie, 0 stopped
CPU0 states: 1.2% user, 1.2% system, 0.0% nice, 96.4% idle
CPU1 states: 0.0% user, 1.0% system, 0.0% nice, 98.4% idle
Mem: 4012024K av, 3847220K used, 164804K free, 0K shrd, 227372K buff
Swap: 2097136K av, 79308K used, 2017828K free 2986736K cached
--------------------------------------
HostMatters/NAC
2.2 secs (3.8e+03 Kbytes/sec),
2.5 secs (3.3e+03 Kbytes/sec),
2.85 secs (2.9e+03 Kbytes/sec),
2.23 secs (3.7e+03 Kbytes/sec),

load average: 7.02, 7.11, 7.29, 171 processes: 163 sleeping, 7 running, 0 zombie, 1 stopped
CPU0 states: 94.0% user, 5.0% system, 0.0% nice, 0.0% idle
CPU1 states: 92.0% user, 7.0% system, 0.0% nice, 0.0% idle
Mem: 1033628K av, 912772K used, 120856K free, 0K shrd, 91772K buff
Swap: 524264K av, 125096K used, 399168K free 516364K cached
--------------------------------------
Spenix.com/NAC
11.6 secs (7.1e+02 Kbytes/sec),
11.7 secs (7.1e+02 Kbytes/sec)
12.7 secs (6.5e+02 Kbytes/sec)
11.6 secs (7.2e+02 Kbytes/sec)
11.7 secs (7.1e+02 Kbytes/sec),

load average: 2.77, 2.40, 2.40, 180 processes: 170 sleeping, 6 running, 2 zombie, 2 stopped
CPU states: 15.6% user, 15.8% system, 2.3% nice, 11.8% idle
Mem: 1548548K av, 1527264K used, 21284K free, 0K shrd, 106884K buff
Swap: 2096472K av, 54028K used, 2042444K free 1110436K cached
--------------------------------------
SplashHost/Dallas NOC
11.9 secs (7e+02 Kbytes/sec)
12 secs (7e+02 Kbytes/sec)
14 secs (5.9e+02 Kbytes/sec)
12.3 secs (6.8e+02 Kbytes/sec)
9.82 secs (8.5e+02 Kbytes/sec)

load average: 0.35, 0.54, 0.53, 3 processes: 2 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.3% user, 1.2% system, 0.3% nice, 0.6% idle
Mem: 515796K av, 509436K used, 6360K free, 0K shrd, 62680K buff
Swap: 1020088K av, 142860K used, 877228K free 268028K cached
--------------------------------------
FluidHosting/Internap
VDS account+ WHM/CPanel (RedHat 7.1)
2.89 secs (2.9e+03 Kbytes/sec)
2.9 secs (2.9e+03 Kbytes/sec)
2.99 secs (2.8e+03 Kbytes/sec)
2.85 secs (2.9e+03 Kbytes/sec)
2.86 secs (2.9e+03 Kbytes/sec)

load average: 0.00, 0.00, 0.00, 39 processes: 37 sleeping, 2 running, 0 zombie, 0 stopped
CPU0 states: 0.0% user, 6.0% system, 0.0% nice, 93.0% idle
CPU1 states: 0.1% user, 3.0% system, 0.0% nice, 95.0% idle
Mem: 2054176K av, 2043152K used, 11024K free, 0K shrd, 35220K buff
Swap: 2096440K av, 444204K used, 1652236K free 1359804K cached
--------------------------------------

Not all NAC accounts are the same, maybe different networking configuraton in server-side.
The FH's account is very stable, in fact its the newly announced VDS plus WHM/CPanel, not shared account.

My ranking:
(1) VO, FH/Internap (2) NAC/HM (3) Others.
To waste time to do traceroute, and some shared accounts are not allowed to do so.
Any numbers for DV2, 56 Marietta,SmartNOC?
This was a long thread before I read it.

The best our VO Ventures Online would do after 6 tries is:

227 Entering Passive Mode (192,48,96,9,129,35)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 16.6 secs (5e+02 Kbytes/sec)

I wonder how somebody would be able to dig this old thread :)

From one of our servers at Internap,

- with single FTP connection, we are able to burst to around 3 MB/s (24 Mbps).
- with up to four simultaenous FTP connections, we are able to burst to 3.1 MB/s on each connection (4x3.1 MB/s = 99.2 Mbps)
- with five simultaneours FTP connections, we are able to burst to 2.5 MB/s on each connection (5x2.5 MB/s = 100 Mbps)
- with six simultaneours FTP connections, we are able to burst to an average of 2 MB/s on each connection (6x2 MB/s = 96 Mbps)

So we can burst up to the 100 Mbps switch port :)

shared @ NAC
2.56 sec 3.2e +03 KBytes/sec

shared @ NOCSTER
3.2 sec 2.6e+03 KBytes/sec

Aleron/Defender Hosting in Northern Virginia. Ping is low:

PING ftp.uu.net (192.48.96.9) from 204.157.**.**: 56(84) bytes of data.
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=1 ttl=242 time=6.29 ms
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=2 ttl=242 time=6.56 ms
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=3 ttl=242 time=6.59 ms
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=4 ttl=242 time=6.42 ms
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=5 ttl=242 time=6.32 ms
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=6 ttl=242 time=6.21 ms
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=7 ttl=242 time=6.28 ms
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=8 ttl=242 time=6.29 ms
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=9 ttl=242 time=6.48 ms
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=10 ttl=242 time=6.61 ms

--- ftp.uu.net ping statistics ---
10 packets transmitted, 10 received, 0% loss, time 9024ms
rtt min/avg/max/mdev = 6.216/6.408/6.614/0.147 ms

and,
Transfer is quick (two trials):

[root@****** root]# wget ftp://ftp.uu.net/uumap.tar.Z
--17:52:09-- ftp://ftp.uu.net/uumap.tar.Z
=> `uumap.tar.Z'
Resolving ftp.uu.net... done.
Connecting to ftp.uu.net[192.48.96.9]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD not needed.
==> PORT ... done. ==> RETR uumap.tar.Z ... done.
Length: 8,520,221 (unauthoritative)

100%[====================================>] 8,520,221 7.26M/s ETA 00:00

17:52:32 (7.26 MB/s) - `uumap.tar.Z' saved [8520221]

[root@****** root]# wget ftp://ftp.uu.net/uumap.tar.Z
--17:54:03-- ftp://ftp.uu.net/uumap.tar.Z
=> `uumap.tar.Z.1'
Resolving ftp.uu.net... done.
Connecting to ftp.uu.net[192.48.96.9]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD not needed.
==> PORT ... done. ==> RETR uumap.tar.Z ... done.
Length: 8,520,221 (unauthoritative)

100%[====================================>] 8,520,221 7.39M/s ETA 00:00

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,225,223)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 2.8 secs (3e+03 Kbytes/sec)

This is from GlobalCompass in Atlanta.

How do you determine how fast it is from (3e+03 Kbytes/sec)?

Originally posted by Weberz
How do you determine how fast it is from (3e+03 Kbytes/sec)?

That's scientific notation.

In this case, you start with three and multiply times 10 three times. In other words, you move the decimal place over to the right three times:

3 --> 30 --> 300 --> 3000 Kbytes/sec

Originally posted by atr
Aleron/Defender Hosting in Northern Virginia. Ping is low:

PING ftp.uu.net (192.48.96.9) from 204.157.**.**: 56(84) bytes of data.
64 bytes from ftp.UU.NET (192.48.96.9): icmp_seq=1 ttl=242 time=6.29 ms


Do you have a traceroute for that? Looks like you're about two hops from the site itself, since UUnet is headquartered in Northern Virginia.

This is the only download time I've seen faster than our QuickServe customer ;) and we aren't even a UUnet customer anymore.

Kevin

Originally posted by sigma


Do you have a traceroute for that? Looks like you're about two hops from the site itself, since UUnet is headquartered in Northern Virginia.

This is the only download time I've seen faster than our QuickServe customer ;) and we aren't even a UUnet customer anymore.

[root@***** root]# traceroute ftp.uu.net
traceroute to ftp.uu.net (192.48.96.9), 30 hops max, 38 byte packets
1 colo.aleron.com (204.157.6.1) 0.342 ms 0.210 ms 0.194 ms
2 ge6-0.ar.alrherva.aleron.net (205.198.0.77) 0.213 ms 0.150 ms 0.127 ms
3 vlan10.as.eqxashva.aleron.net (205.198.0.40) 2.008 ms 1.955 ms 1.987 ms
4 ge-1-1-0.100.ar1.DCA3.gblx.net (67.17.134.229) 2.064 ms 2.069 ms 2.039 ms
5 pos4-2-622M.cr2.WDC2.gblx.net (64.215.195.14) 2.966 ms 2.950 ms 2.955 ms
6 so2-1-0-622M.br1.WDC2.gblx.net (208.178.174.62) 3.034 ms 3.014 ms 3.015 ms
7 96.ATM1-0.BR1.DCA6.ALTER.NET (204.255.168.141) 4.107 ms 3.948 ms 3.994 ms
8 0.so-4-0-0.XL1.DCA6.ALTER.NET (152.63.38.134) 4.209 ms 4.265 ms 4.108 ms
9 0.so-0-0-0.XR1.DCA6.ALTER.NET (152.63.35.113) 4.161 ms 4.157 ms 4.179 ms
10 185.at-1-0-0.CL1.IAD5.ALTER.NET (152.63.34.190) 5.979 ms 6.172 ms 6.168 ms
11 500.ATM7-0.GW3.IAD5.ALTER.NET (152.63.37.253) 6.082 ms 6.003 ms 5.986 ms
12 pos5-0.soesr1.ash.ops.us.uu.net (207.18.173.162) 5.930 ms 5.852 ms 6.203 ms
13 gig1-0.esr-b-10-9-2.ash.ops.us.uu.net (198.5.240.36) 6.491 ms 6.395 ms 6.752 ms
14 neo-ftp.uu.net (198.5.241.101) 6.481 ms 6.576 ms 6.351 ms

IMO geographical distance plays a much larger role in connectivity performance than many here give it credit for. I could have my own gig-e here in Washington, but it's still going to take at least 60-70 ms to ping across the country, even with no hops in between. For example, look at this excerpt from a traceroute from my server to he.net:

6 so-1-0-0.cr1.dca2.us.mfnx.net (208.184.233.125) 4.069 ms 4.151 ms 4.156 ms
7 so-3-0-0.mpr3.sjc2.us.mfnx.net (208.184.233.133) 75.747 ms 75.533 ms 75.631 ms


Here's an excerpt from a cross-country trace over Verio:

8 p16-7-0-0.r02.mclnva02.us.bb.verio.net (129.250.5.10) 3.509 ms 3.470 ms 3.334 ms
9 p16-0-1-2.r20.plalca01.us.bb.verio.net (129.250.2.192) 82.688 ms 77.419 ms 73.849 ms


Cogent:

4 p3-0.br01.dca01.atlas.psi.net (154.54.1.77) 1.365 ms 1.317 ms 1.302 ms
5 p13-0.core02.dca01.atlas.cogentco.com (154.54.1.61) 30.915 ms 30.898 ms 31.106 ms
6 p15-0.core01.dca01.atlas.cogentco.com (66.28.4.21) 31.204 ms 34.463 ms 31.133 ms
7 p10-0.core02.sfo01.atlas.cogentco.com (66.28.4.209) 76.780 ms 76.738 ms 76.924 ms


Yahoo/Aleron:

4 yahoo-peer.as.eqxashva.aleron.net (204.157.5.98) 2.037 ms 2.068 ms 2.046 ms
5 ge-2-2-0-p805.pat2.pao.yahoo.com (216.115.98.45) 82.543 ms 82.549 ms 82.609 ms


Level3:

6 so-7-0-0.mp1.Washington1.Level3.net (64.159.1.189) 2.735 ms 2.772 ms 2.770 ms
7 so-3-0-0.mp2.SanJose1.Level3.net (64.159.1.130) 83.494 ms 83.538 ms 83.590 ms


Cable & Wireless:

6 acr1-loopback.Restonrst.cw.net (206.24.178.61) 3.264 ms 3.224 ms 2.928 ms
7 agr4-loopback.SantaClara.cw.net (208.172.146.104) 88.011 ms 88.063 ms 88.200 ms


Anyways, you get the idea.

Delicated @ Rackshack

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,124,21)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 6.2 secs (1.3e+03 Kbytes/sec)
1.3MB/sec

Delicated @ Rackshack

traceroute to ftp.uu.net (192.48.96.9), 30 hops max, 38 byte packets
1 207.44.158.1 (207.44.158.1) 0.389 ms 0.191 ms 0.269 ms
2 207.218.223.1 (207.218.223.1) 0.438 ms 0.363 ms 0.336 ms
3 everyoneint-1.s2333b.usdlls2-j20c.savvis.net (64.243.79.13) 6.191 ms 6.229 ms 6.299 ms
4 500.POS3-0.GW5.DFW9.ALTER.NET (157.130.155.233) 7.397 ms 7.175 ms 7.221 ms
5 130.at-5-0-0.XR1.DFW9.ALTER.NET (152.63.100.42) 7.434 ms 7.378 ms 7.506 ms
6 0.so-2-1-0.XL1.DFW9.ALTER.NET (152.63.101.249) 6.977 ms 7.078 ms 7.112 ms
7 0.so-0-0-0.TL1.DFW9.ALTER.NET (152.63.0.193) 7.959 ms 7.212 ms 6.980 ms
8 0.so-6-0-0.TL1.DCA8.ALTER.NET (152.63.3.198) 40.685 ms 40.415 ms 40.293 ms
9 0.so-4-3-0.XL1.DCA8.ALTER.NET (152.63.144.50) 40.504 ms 40.443 ms 40.412 ms
10 189.at-1-0-0.CL1.IAD5.ALTER.NET (152.63.34.238) 38.671 ms 38.200 ms 38.255 ms
11 500.ATM6-0.GW3.IAD5.ALTER.NET (152.63.38.5) 38.382 ms 38.774 ms 38.097 ms
12 pos5-0.soesr1.ash.ops.us.uu.net (207.18.173.162) 38.437 ms 38.355 ms 38.560 ms
13 gig1-0.esr-b-10-9-1.ash.ops.us.uu.net (198.5.240.35) 38.687 ms 40.763 ms 38.829 ms
14 neo-ftp.uu.net (198.5.241.101) 38.436 ms 38.917 ms 38.496 ms

This is from one of my servers in NAC.

150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 1.62 secs (5.1e+03 Kbytes/sec)

might as well join in...

@ HE.net
8520221 bytes received in 10.9 secs (7.6e+02 Kbytes/sec)

@ DV2
8520221 bytes received in 5.67 secs (1.5e+03 Kbytes/sec)

@ VONOC
8520221 bytes received in 18 secs (4.6e+02 Kbytes/sec)

At Servepath today !!!!!

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,110,242)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).


226 Transfer complete.
8520221 bytes received in 557 secs (15 Kbytes/sec)

That s_cks!!

150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 2.62 secs (3.2e+03 Kbytes/sec)

:eek: :eek:

Well, I'm fairly pleased......:D

I prefer it if it can burst the other way.. (upload) since download is hardly used. =x

I figured I would give this a shot on my cable modem :)

150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
Received 8520221 bytes in 18.3 secs, (4.46 Mbps), transfer succeeded
226 Transfer complete.

-----------------------------------------------------

Not Bad :D

UnitedColo ,

8520221 bytes transferred in 12 seconds (677.6K/s)

...

Dektong,

You should compile these results in a list to show the results as the thread is becoming very large.

I think it would be interesting to see in one place. Granted, there are a few variables to consider, but it would give everyone a good overall picture of the speed of providers.

8520221 bytes received in 5.44 secs (1.5e+03 Kbytes/sec)
From ThePlanet.com

unitedcolo :

230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,14,206)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 10.7 secs (7.8e+02 Kbytes/sec)

226 Transfer complete.
8520221 bytes received in 1.80 seconds (4.51 MB/s)

ReliableServers.Net

ftp> get uumap.tar.Z
local: uumap.tar.Z remote: uumap.tar.Z
227 Entering Passive Mode (192,48,96,9,234,161)
150 Opening BINARY mode data connection for uumap.tar.Z (8520221 bytes).
226 Transfer complete.
8520221 bytes received in 1.54 secs (5.4e+03 Kbytes/sec)