OVH Community, your new community space.

Test File


Myatu
02-07-2010, 20:31
I don't see any kernel drivers in use for these (try "-vv" instead of "-v", though it shouldn't differ on the distro).

Do you have any loaded at all? Check with "lsmod | grep ata".

Speedy059
02-07-2010, 09:48
Myatu,

Not much of that is making sense, but here is the output:

Code:
[root@openvz ~]# lspci
00:00.0 Host bridge: Intel Corporation 82G35 Express DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03)
00:19.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801H (ICH8 Family) 4 port SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801H (ICH8 Family) 2 port SATA IDE Controller (rev 02)
03:00.0 IDE interface: JMicron Technology Corp. JMB368 IDE controller
04:05.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 70)
Code:
[root@openvz ~]# lspci -v -s 00:1f.2
00:1f.2 IDE interface: Intel Corporation 82801H (ICH8 Family) 4 port SATA IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
        Subsystem: Intel Corporation Unknown device d701
        Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 50
        I/O ports at 
        I/O ports at 
        I/O ports at 
        I/O ports at 
        I/O ports at 2410 [size=16]
        I/O ports at 2400 [size=16]
        Capabilities: [70] Power Management version 3

[root@openvz ~]# lspci -v -s 00:1f.5
00:1f.5 IDE interface: Intel Corporation 82801H (ICH8 Family) 2 port SATA IDE Controller (rev 02) (prog-if 85 [Master SecO PriO])
        Subsystem: Intel Corporation Unknown device d701
        Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 50
        I/O ports at 2428 [size=8]
        I/O ports at 244c [size=4]
        I/O ports at 2420 [size=8]
        I/O ports at 2448 [size=4]
        I/O ports at 20f0 [size=16]
        I/O ports at 20e0 [size=16]
        Capabilities: [70] Power Management version 3
I just don't see how/where to adjust settings to fix this.

elvis1
01-07-2010, 23:26
off topic:

from a NYC VPS ( 10 mbit / 6 bucks):

# wget ftp://ftp.ovh.net/test.bin
--2010-07-02 02:22:17-- ftp://ftp.ovh.net/test.bin
=> `test.bin'
Resolving ftp.ovh.net... 213.186.33.9
Connecting to ftp.ovh.net|213.186.33.9|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD not needed.
==> SIZE test.bin ... 104857600
==> PASV ... done. ==> RETR test.bin ... done.
Length: 104857600 (100M)

100%[================================================== ================================================== ===============>] 104,857,600 3.26M/s in 48s

Speedy059
01-07-2010, 22:44
Quote Originally Posted by marks
I've checked your server and, it's not booting up from the hd by itself. The message it's showing is:

"No init found"

you can try to fix it using rescue mode, but this added to the previous problems, make me think that the server is quite misconfigured. Would you consider reinstalling it?
I ordered a second server. Then ordered the Virtual Rack for both of them. Now i'm just trying to figure out how to get my /24 block assigned to both servers in that VLAN so they can share IP's. Then I can then move my clients off on to the new server and reinstall the server that just crashed.

After ordering the Virtual Rack, I still don't know what I should be doing as I don't see any options to get both servers to have the /24 block assigned. I want them to be able to share the IP's so we can move clients in-between servers without having to reassign IP's to each server or have to change our clients IP's.

marks
01-07-2010, 12:20
I've checked your server and, it's not booting up from the hd by itself. The message it's showing is:

"No init found"

you can try to fix it using rescue mode, but this added to the previous problems, make me think that the server is quite misconfigured. Would you consider reinstalling it?

Speedy059
30-06-2010, 23:55
I hope OVH brings my server online so I can check. I haven't been able to troubleshoot it since it's been delivered a month ago. I lose connection as soon as I connect to it.

Myatu
30-06-2010, 23:01
Quote Originally Posted by Speedy059
hmmm, not sure which module it would be. If I could login to the server I would try and figure it out lol.
That would help Simply do a "lspci" which will give you output along the lines of these:

Code:
...
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01)
...
You can pull up more details then with "lspci -v -s 00:1f.2" (or whatever the ID in front of the "IDE" or "SATA IDE" controller). You'll get an output like this:

Code:
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01) (prog-if 8f [Master SecP SecO PriP PriO])
        Subsystem: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller
        Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 17
        I/O ports at e0e0 [size=8]
        I/O ports at e0d0 [size=4]
        I/O ports at e0c0 [size=8]
        I/O ports at e0b0 [size=4]
        I/O ports at e0a0 [size=16]
        Capabilities: [70] Power Management version 2
        Kernel driver in use: ata_piix
        Kernel modules: ata_piix, pata_acpi, ata_generic
You need to check if whatever is listed in "Kernel modules:" and "Kernel driver in use:" match the controller.

"ata_piix" is fairly universal (and for SATA), so make sure to set "CONFIG_ATA_PIIX" to "Yes" if you compile your own.

Also do a "cat /var/log/dmesg | grep ata" to see any possible issues. For example:

Code:
ata_piix 0000:00:1f.1: version 2.12
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xe0f0 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xe0f8 irq 15
ata2: port disabled. ignoring.
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
scsi2 : ata_piix
scsi3 : ata_piix
ata3: SATA max UDMA/133 cmd 0xe0e0 ctl 0xe0d0 bmdma 0xe0a0 irq 17
ata4: SATA max UDMA/133 cmd 0xe0c0 ctl 0xe0b0 bmdma 0xe0a8 irq 17
ata3.00: ATA-8: ST3750330AS, SD1A, max UDMA/133
ata3.00: 1465149168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata3.00: configured for UDMA/133
ata4.00: ATA-8: ST3750330AS, SD1A, max UDMA/133
ata4.00: 1465149168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata4.00: configured for UDMA/133
So on ata0, there's a PATA device - a DVD drive. On ata3 and ata4 you can see it uses SATA. You should obviously see something similar and not 4x "PATA".

Speedy059
30-06-2010, 22:37
hmmm, not sure which module it would be. If I could login to the server I would try and figure it out lol.

Myatu
30-06-2010, 22:36
The Proxmox suggestion was simply the "easy way out", as in "no configuration to do" But it's not the kernel that's the issue, it's the loaded module.

Speedy059
30-06-2010, 22:20
We use a certain openvz setup for all of our servers and locations around the world. This is the first time I've had hard drives not being compatible with the latest openvz kernels.

Myatu
30-06-2010, 21:58
Did you install the OS via the vKVM by any chance? Anyway, look at your /var/log/messages output to see if there's an issue there with the drivers. You can also blacklist the incorrect module, provided you have the right module loaded (ie., in /etc/modules).

If that's a bit much, why not install Proxmox? You don't have to use all its features, but its fully compatible with OVH's hardware and has the openvz kernel patches.

Speedy059
30-06-2010, 21:26
Problem is that I have to use an openvz kernel, otherwise it would take down all the VM's.

Are their drivers I can download from somewhere for these hard drives?

marks
30-06-2010, 12:58
hey, Speedy059

following the ticket and talking to the engineers:

you're using wget to test speeds, but in your case, that's not a reliable way to do it. As you've been told several times in the ticket, you've got a misconfiguration in your server.

Your server shows this:
Code:
Disk /dev/hda: 750.1 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot	    Start	  End	   Blocks   Id 
System
/dev/hda1   *		1	  262	  2098145   fd 
Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/hda2	      262	90153	722053120   fd 
Linux raid autodetect
/dev/hda3	    90153	91201	  8420736   82 
Linux swap / Solaris

Disk /dev/hdc: 750.1 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot	    Start	  End	   Blocks   Id 
System
/dev/hdc1		1	  262	  2098145   fd 
Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/hdc2	      262	90153	722053120   fd 
Linux raid autodetect
/dev/hdc3	    90153	91201	  8420736   82 
Linux swap / Solaris
i.e. your drives are detected as IDE. That's a problem. In rescue mode, they are detected as SATA, as they should be:

Code:
Disk identifier: 0x000f285e

   Device Boot	    Start	  End	   Blocks   Id 
System
/dev/sda1   *		1	  262	  2098145   fd 
Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2	      262	90153	722053120   fd 
Linux raid autodetect
/dev/sda3	    90153	91201	  8420736   82 
Linux swap / Solaris

Disk /dev/sdb: 750.1 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000155b2

   Device Boot	    Start	  End	   Blocks   Id 
System
/dev/sdb1		1	  262	  2098145   fd 
Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2	      262	90153	722053120   fd 
Linux raid autodetect
/dev/sdb3	    90153	91201	  8420736   82 
Linux swap / Solaris
I'm told that's a problem in your system.

This problem makes your wget tests unreliable. This speed results given by wget repend on the Apache or the ftp server you've got in your server, which at the same time depend on the reading speed.

You want to do reliable speed test? Run this in your server:

Code:
nc -l -p 7777 > /dev/null
and this from any other server:

Code:
dd if=/dev/zero bs=1M count=100 | nc  7777
or, even better, do the test in rescue mode (this commands are for a Debian OS, like our rescue mode).


As you've been advised in the ticket, you have to check different causes for your problem:

- bad driver for disks
- synflood on IRC
- kill an defunct on php / cgi

Regarding the first one, you can try to use one of our network kernels (choose them from Netboot) or update the kernel yourself.

Let us know if we can provide more info, but the ticket you've got open is not the correct place to ask for help anymore. The engineers have done far more than the usual to prove to you that's not a problem with the network.

Get in touch with us in the customer support if you need more help.

freshwire
30-06-2010, 00:46
The 9.82 MB/s I posted was outside the network. So is it just 1 particular route that is slow?

Myatu
29-06-2010, 20:53
Did you send them _Lemon_'s traceroute and speedtest as well?

Speedy059
29-06-2010, 19:29
OVH is giving me a big headache. They keep telling me it's my "the hard drives, the hard drives!". This is total garbage especially when some of you are able to download from my server at 45MB/s within their network. This means that the server has the capacity to upload at those speeds out-of-network as long as their network isn't throttling it. I can't download over 1MB/s outside of the network. Sure, the openvz kernel slows down the HD's a little bit, but there is still tons of capacity there as you guys have proven. I've never worked with a datacenter who is in so much denial about their own network and wont even take into consideration that there **MIGHT** be a problem with my servers' connection...

It's been a month, and they wont do a single thing. Why do you guys stay with these people?

freshwire
26-06-2010, 04:20
Code:
--2010-06-26 03:15:14--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `test.bin.1'

100%[==================================================================================>] 104,857,600 9.02M/s   in 10s

2010-06-26 03:15:24 (9.82 MB/s) - `test.bin.1' saved [104857600/104857600]
Code:
 Host                                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 82.113.153.17                                       0.0%    19    0.4   0.4   0.4   0.6   0.1
 2. lon-ixn-edge-03.xtraordinary.net.uk                 0.0%    19   14.6   1.3   0.4  14.6   3.2
 3. sw1.tc.lon.ovh.net                                  5.6%    18    1.2  13.0   0.9 135.8  34.4
 4. 20g.vss-2-6k.routers.chtix.eu                      11.1%    18   11.5  18.2   4.7  94.5  24.2
 5. ns207234.ovh.net                                    0.0%    18    4.6  10.4   4.4  59.1  15.7

_Lemon_
25-06-2010, 22:54
Quote Originally Posted by Myatu
Now that paints a different picture. That's definitely not outside of OVH's network realm - both LeaseWeb and OVH use AMS-IX. On the same note, a lot of overseas traffic goes through AMS-IX too... Maybe rodents are eating the link to Amsterdam again
Code:
[badger ~] traceroute 94.23.203.64
traceroute to 94.23.203.64 (94.23.203.64), 30 hops max, 40 byte packets
 1  85.17.72.142 (85.17.72.142)  0.326 ms  0.366 ms  0.572 ms
 2  be21.crs.evo.leaseweb.net (85.17.100.221)  1.582 ms  1.599 ms  1.584 ms
 3  amsix.routers.ovh.net (195.69.145.231)  199.119 ms *  198.972 ms
 4  * 20g.vss-2-6k.routers.chtix.eu (94.23.122.113)  9.090 ms *
 5  ns207234.ovh.net (94.23.203.64)  16.068 ms  16.066 ms  16.051 ms
It's definitely going through the AMS-IX connection however the ping times vary a lot as soon as it hits the OVH network (this was the best I had).

You can also see a huge difference the speeds they each have: Leaseweb 140Gbps ( https://www.peeringdb.com/private/pa...iew.php?id=678 ) vs OVH 40Gbps ( https://www.peeringdb.com/private/pa...ew.php?id=1264 ).

Quote Originally Posted by Speedy059
The thing is, we aren't worried about the transit. Yes we are from the US, but our clients using this server are from Europe. Every one of them is complaining about speeds. We don't care the least about transit as we don't need it. We need speeds in Europe to be faster than 100KB/s outside of OVH network. It isn't an HD issue since in-network servers can download the file just fine. They are beating the bush on this one with me and wont fix their network and just keep having me run around with HD issues....
I have found some servers perform better than others but all start off performing great. It's like the server "ticks down" in priority as OVH see it costing more than their worth.

Speedy059
25-06-2010, 20:17
The thing is, we aren't worried about the transit. Yes we are from the US, but our clients using this server are from Europe. Every one of them is complaining about speeds. We don't care the least about transit as we don't need it. We need speeds in Europe to be faster than 100KB/s outside of OVH network. It isn't an HD issue since in-network servers can download the file just fine. They are beating the bush on this one with me and wont fix their network and just keep having me run around with HD issues....

Myatu
25-06-2010, 19:12
Quote Originally Posted by _Lemon_
Here are some transfers from external servers:

Leaseweb, NL (1Gbps):

Code:
[badger ~] wget http://94.23.203.64/test.bin
--2010-06-25 16:12:58--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `test.bin.1'

100%[===================================================================================================================>] 104,857,600  371K/s   in 4m 26s  

2010-06-25 16:17:33 (386 KB/s) - `test.bin.1' saved [104857600/104857600]
Now that paints a different picture. That's definitely not outside of OVH's network realm - both LeaseWeb and OVH use AMS-IX. On the same note, a lot of overseas traffic goes through AMS-IX too... Maybe rodents are eating the link to Amsterdam again

_Lemon_
25-06-2010, 17:26
Here are some transfers from external servers:

Leaseweb, NL (1Gbps):

Code:
[badger ~] wget http://94.23.203.64/test.bin
--2010-06-25 16:12:58--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `test.bin.1'

100%[===================================================================================================================>] 104,857,600  371K/s   in 4m 26s  

2010-06-25 16:17:33 (386 KB/s) - `test.bin.1' saved [104857600/104857600]
Softlayer, Washington DC (1Gbps):

Code:
[peacotum ~] wget http://94.23.203.64/test.bin
--2010-06-25 16:13:17--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `test.bin.1'

100%[===================================================================================================================>] 104,857,600  248K/s   in 8m 42s  

2010-06-25 16:22:20 (196 KB/s) - `test.bin.1' saved [104857600/104857600]
That's something very different. It turns out that I have two servers on the same subnet (so presumably, same rack), let's test with these bad boys. (These tests were done concurrently as I couldn't be bothered waiting around for the other two, they fluctuated a LOT).

Code:
[viridian ~] wget http://94.23.203.64/test.bin
--2010-06-25 16:01:14--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `test.bin'

100%[===================================================================================================================>] 104,857,600 2.61M/s   in 55s     

2010-06-25 16:02:13 (1.81 MB/s) - `test.bin' saved [104857600/104857600]

[viridian ~] uptime 
 16:02:15 up 87 days, 21:46,  2 users,  load average: 0.15, 0.18, 0.12

[thistle ~] wget http://94.23.203.64/test.bin
--2010-06-26 00:13:48--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `test.bin'

100%[===================================================================================================================>] 104,857,600 7.11M/s   in 68s     

2010-06-26 00:14:56 (1.47 MB/s) - `test.bin' saved [104857600/104857600]

[thistle ~] uptime 
 00:15:18 up 117 days, 21:08,  1 user,  load average: 0.21, 0.14, 0.16
Just to verify whether these two servers are working as expected:

Code:
[thistle ~] wget http://viridian.feralhosting.com/test.bin
--2010-06-26 00:17:10--  http://viridian.feralhosting.com/test.bin
Resolving viridian.feralhosting.com... 94.23.203.59
Connecting to viridian.feralhosting.com|94.23.203.59|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 100000000 (95M) [application/octet-stream]
Saving to: `test.bin.1'

100%[===================================================================================================================>] 100,000,000 42.5M/s   in 2.2s    

2010-06-26 00:17:12 (42.5 MB/s) - `test.bin.1' saved [100000000/100000000]
Now this one's interesting (from Badger the LW server):

Code:
[badger ~] wget http://viridian.feralhosting.com/test.bin
--2010-06-25 16:21:33--  http://viridian.feralhosting.com/test.bin
Resolving viridian.feralhosting.com... 94.23.203.59
Connecting to viridian.feralhosting.com|94.23.203.59|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 100000000 (95M) [application/octet-stream]
Saving to: `test.bin'

100%[===================================================================================================================>] 100,000,000 3.41M/s   in 30s     

2010-06-25 16:22:03 (3.20 MB/s) - `test.bin' saved [100000000/100000000]

[badger ~] wget ftp://ftp.ovh.net/test.bin
--2010-06-25 16:22:06--  ftp://ftp.ovh.net/test.bin
           => `test.bin.1'
Resolving ftp.ovh.net... 213.186.33.9
Connecting to ftp.ovh.net|213.186.33.9|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD not needed.
==> SIZE test.bin ... 104857600
==> PASV ... done.    ==> RETR test.bin ... done.
Length: 104857600 (100M)

100%[===================================================================================================================>] 104,857,600 8.43M/s   in 12s     

2010-06-25 16:22:18 (8.41 MB/s) - `test.bin.1' saved [104857600]

RapidSpeeds
25-06-2010, 15:39
Quote Originally Posted by elvis1
the ftp://ftp.ovh.net/test.bin file has been downloaded at VERY good speeds from USA @WHT. Obviously they must spend some extra dough on it to make it look even better that what an average Joe ( Octave would be here :P ) would be has in his server :P
Course they do mate, it's all about marketing Anyone with a company who wants to sell servers to a market they have no peering in would do the same.

elvis1
25-06-2010, 14:38
Quote Originally Posted by Myatu
Put the testfile on a ram disk, then you know it isn't the HD

If its transit peering, then it isn't guaranteed (and they can't really, unless they have full control over it or pay mucho bucks for an SLA - meaning you won't get your server at the price you do now).

But where to/from are the troubled speeds? If you're doing a USA location <-> OVH test, you can pretty much expect puny speeds...
the ftp://ftp.ovh.net/test.bin file has been downloaded at VERY good speeds from USA @WHT. Obviously they must spend some extra dough on it to make it look even better that what an average Joe ( Octave would be here :P ) would be has in his server :P

Myatu
25-06-2010, 12:55
Put the testfile on a ram disk, then you know it isn't the HD

If its transit peering, then it isn't guaranteed (and they can't really, unless they have full control over it or pay mucho bucks for an SLA - meaning you won't get your server at the price you do now).

But where to/from are the troubled speeds? If you're doing a USA location <-> OVH test, you can pretty much expect puny speeds...

Speedy059
25-06-2010, 10:12
It's just that I have OVH support telling me that my hard drives are to blame....when clearly it can push pretty high speeds internally. I can't convince them otherwise. The 1Mbps out-of-network speeds seems to be 'ok' with them. I don't get it???

RapidSpeeds
25-06-2010, 06:14
Quote Originally Posted by Myatu
He did post *here* Should have posted on webhostingtalk or something otherwise...
true why I said should have been more specific; though sometimes you know what someone means without having to ask it, as he was obviously having speed problems otherwise he wouldn't be posting a test file with his servers IP, therefore rendering tests by other ovh servers useless

Quote Originally Posted by Speedy059
Yes, external sources would of been better. lol
I rest my case

Speedy059
25-06-2010, 01:15
Yes, external sources would of been better. lol

Myatu
24-06-2010, 14:56
He did post *here* Should have posted on webhostingtalk or something otherwise...

RapidSpeeds
24-06-2010, 14:37
I think he is probably getting at people to test with an external server, instead of one using the same network which is obviously going to be a lot faster...

Then again if he was, should have been more specific

YouWhat
24-06-2010, 03:58
wget http://94.23.203.64/test.bin
--2010-06-24 03:53:33-- http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `test.bin'

100%[======================================>] 104,857,600 59.0M/s in 1.7s

2010-06-24 03:53:35 (59.0 MB/s) - `test.bin' saved [104857600/104857600]
From RBX-3

Myatu
24-06-2010, 00:31
Code:
wget http://94.23.203.64/test.bin -O /dev/null
--2010-06-24 01:26:03--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[======================================>] 104,857,600 50.9M/s   in 2.0s

2010-06-24 01:26:05 (50.9 MB/s) - `/dev/null' saved [104857600/104857600]

wget http://94.23.203.64/test.bin -O /dev/null
--2010-06-24 01:26:52--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[======================================>] 104,857,600 49.5M/s   in 2.0s

2010-06-24 01:26:54 (49.5 MB/s) - `/dev/null' saved [104857600/104857600]

wget http://94.23.203.64/test.bin -O /dev/null
--2010-06-24 01:27:06--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[======================================>] 104,857,600 42.2M/s   in 2.4s

2010-06-24 01:27:09 (42.2 MB/s) - `/dev/null' saved [104857600/104857600]
About the same results for 3 tests in a row.

Iray
23-06-2010, 23:22
c250g
Code:
wget http://94.23.203.64/test.bin
--2010-06-24 00:19:30--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `test.bin'

100%[======================================>] 104,857,600 10.7M/s   in 9.6s

2010-06-24 00:19:40 (10.4 MB/s) - `test.bin' saved [104857600/104857600]

MicroChip123
23-06-2010, 22:33
OVH RBX1 - 9.74 MB/s

_Lemon_
23-06-2010, 22:32
It seems to vary a lot, but this is from a HG XL under no load/use:

Code:
[thoth ~] wget http://94.23.203.64/test.bin
--2010-06-24 05:39:09--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `test.bin'

100%[===================================================================================================================>] 104,857,600 21.4M/s   in 6.5s    

2010-06-24 05:39:16 (15.4 MB/s) - `test.bin' saved [104857600/104857600]

[thoth ~] wget http://94.23.203.64/test.bin
--2010-06-24 05:39:19--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `test.bin.1'

100%[===================================================================================================================>] 104,857,600 37.2M/s   in 2.7s    

2010-06-24 05:39:21 (37.2 MB/s) - `test.bin.1' saved [104857600/104857600]

[thoth ~] wget http://94.23.203.64/test.bin -O /dev/null 
--2010-06-24 05:39:27--  http://94.23.203.64/test.bin
Connecting to 94.23.203.64:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[===================================================================================================================>] 104,857,600 25.9M/s   in 5.4s    

2010-06-24 05:39:32 (18.7 MB/s) - `/dev/null' saved [104857600/104857600]

Speedy059
23-06-2010, 22:18
Can you guys tests this download file on your servers to see what speed you get?

http://94.23.203.64/test.bin

Please let me know what kind of connection you are getting when downloading that file, and where you server is located.