OVH Community, your new community space.

OVH > OVH transfers very slow


tim2718281
23-06-2009, 04:13
Quote Originally Posted by over9000
For example, I can download a file at 2400 kilobytes per second from my RPS to my home, but the same between servers at OVH occurs at 1024 kilobytes per second.

I find this strange as the data is obviously still being read from the same disk as when it is transferred OVH to OVH.
dup deleted

tim2718281
23-06-2009, 04:13
Quote Originally Posted by over9000
For example, I can download a file at 2400 kilobytes per second from my RPS to my home, but the same between servers at OVH occurs at 1024 kilobytes per second.

I find this strange as the data is obviously still being read from the same disk as when it is transferred OVH to OVH.
The data is

a) read from iSCSI disk to server A, at whatever the disk speed is of server A
b) transmitted across the network from server A to server B
c) written from server B to iSCSI disk at whatever the disk speed is of server B

As the transfers to and from iSCSI disk are the slowest part of the work, it's not altogether surprising that when there are two iSCSI operations involved, things can go at about half the speed of when there is one.

As for 100mbps network connection - well, that's how fast it is. Whether your application can deliver data to the network port as fast the port can transmit it depends on your application design. Sure, much of the time, disk I/O is faster than network speeds; and so people assume that if the application is simply copying data from disk to the port, it will run at the port speed. But that's an incorrect assumption. You need to look at how fast your application can generate data to be transmitted, as well as how fast the network can transmit it; your overall speed will be about the lower of the two.

Presumably, if you have CPU cycles to spare, you can gain iSCSI speed by using data compression.

sic
22-06-2009, 16:53
isn't it the other way around? When it was new it was cheaper than it is now?

Andy
22-06-2009, 16:21
Because RPS is a new technology, and like all new technologies it costs more to begin with.

sic
22-06-2009, 16:07
Quote Originally Posted by Andy
The RPS series was designed for personal use and testing, not for serious uptime critical or speed critical applications. It was designed to be the cheapest and closest thing to a real dedicated server, nothing more.
i understand this point andy.

but surely now factoring in extra pricing for speed and storage the rps becomes alot dearer than a kimsufi. so why not simply remove the rps altogether?

freshwire
18-06-2009, 22:24
Burstable is poop! 1GB vps with guaranteed 1.6Ghz share along with 100mbps unlimited ... not cheap.

ruperthair
18-06-2009, 18:27
Quote Originally Posted by Ashley
I think he means memory wise. You don't have much dedicated memory with a VPS, just 'burstable'.
That depends on your provider and the virtualisation technology they use. Xen, for example, does not allow the ISP to 'over commit' RAM so you get dedicated RAM and (hopefully) some swap space. I would always perfer to have 128MB of dedicated RAM and 512MB of swap space than 128MB of dedicated RAM and 512MB (or more) of 'burstable RAM'.

Ashley
18-06-2009, 18:14
Quote Originally Posted by ruperthair
This is a good point but the reliability problems that I saw with the three RPSes I tested put me off using them for anything.




Why's that? As long as your ISP aren't *****s, you should have at least one core available when you need it.
I think he means memory wise. You don't have much dedicated memory with a VPS, just 'burstable'.

ruperthair
18-06-2009, 17:42
Quote Originally Posted by monkey56657
If you are hosting soem really active blog or similar. You can easily store the content in RAM... even if you just use a large cache on your webserver with mod_cache or similar... it is great use for the RPS.
This is a good point but the reliability problems that I saw with the three RPSes I tested put me off using them for anything.


Quote Originally Posted by monkey56657
VPS would not stand up so well in this case.
Why's that? As long as your ISP aren't *****s, you should have at least one core available when you need it.

freshwire
18-06-2009, 17:29
If you are hosting soem really active blog or similar. You can easily store the content in RAM... even if you just use a large cache on your webserver with mod_cache or similar... it is great use for the RPS. VPS would not stand up so well in this case.

unclebob
18-06-2009, 16:28
Quote Originally Posted by ruperthair
The more I think about it, the less I like the idea. To begin with, I was impressed by the idea of sticking so many PCs in one rack, but the more I thought about it and used it, the more I became convinced that VMs are the right way to go.

With gigabit for the iSCSI and less contention on the NAS/SAN, the RPS may come close to a good VM, but I still can't see any reason why you'd want an RPS over a VM.
I agree. I think the economies of scale you can benefit from by using virtualisation outweigh the benefits of a 'cheap' dedicated machine. The sole reason I still have my RPS is for the unlimited bandwidth.

ruperthair
18-06-2009, 15:22
Quote Originally Posted by Ashley
What happens when you download a file from the internet (not your friend) to your disk?
On my VM not at OVH:

Code:
$ wget http://mirror.ovh.net/ubuntu-releases/jaunty/ubuntu-9.04-desktop-i386.iso
--2009-06-18 15:26:09--  http://mirror.ovh.net/ubuntu-releases/jaunty/ubuntu-9.04-desktop-i386.iso
Resolving mirror.ovh.net... 91.121.124.139, 91.121.125.139, 2001:41d0:1:7b8b::1
Connecting to mirror.ovh.net|91.121.124.139|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 732909568 (699M) [application/x-iso9660-image]
Saving to: `ubuntu-9.04-desktop-i386.iso'

11% [===>                                   ] 83,772,480  11.0M/s  eta 58s
On my VM at OVH (it's on a SuperPlan BestOF):

Code:
$ wget http://mirror.ovh.net/ubuntu-releases/jaunty/ubuntu-9.04-desktop-i386.iso
--15:27:08--  http://mirror.ovh.net/ubuntu-releases/jaunty/ubuntu-9.04-desktop-i386.iso
Resolving mirror.ovh.net... 91.121.124.139, 91.121.125.139, 2001:41d0:1:7b8b::1
Connecting to mirror.ovh.net|91.121.124.139|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 732909568 (699M) [application/x-iso9660-image]
Saving to: `ubuntu-9.04-desktop-i386.iso'

10% [===>                                    ] 77,282,335  11.1M/s  eta 57s

Ashley
18-06-2009, 15:14
Quote Originally Posted by ruperthair
There's quite a few places that do VMs in this price range.

You're right that they don't offer unlimited 100mbit/s but with 1MB/s to your 'disk' on the RPS, you're not going to be moving 100mbit for more than a few seconds at a time.
What happens when you download a file from the internet (not your friend) to your disk?

ruperthair
18-06-2009, 14:37
Quote Originally Posted by Ashley
How many other hosts give you all that for £10 a month? Most VPS resellers oversell and end up entering SWAP.
There's quite a few places that do VMs in this price range.

You're right that they don't offer unlimited 100mbit/s but with 1MB/s to your 'disk' on the RPS, you're not going to be moving 100mbit for more than a few seconds at a time.

Andy
18-06-2009, 14:36
Quote Originally Posted by Ashley
Because OVH don't offer VM's.
RPS is cheaper than VM's from most places
Dedicated RAM and processor power
100mbps connection

You can also use OVH's IP load balancing facility (i think) to share the load between upto 8 servers.

How many other hosts give you all that for £10 a month? Most VPS resellers oversell and end up entering SWAP.
+1

Hit it on the head.

Ashley
18-06-2009, 14:12
Because OVH don't offer VM's.
RPS is cheaper than VM's from most places
Dedicated RAM and processor power
100mbps connection

You can also use OVH's IP load balancing facility (i think) to share the load between upto 8 servers.

How many other hosts give you all that for £10 a month? Most VPS resellers oversell and end up entering SWAP.

ruperthair
18-06-2009, 14:09
The more I think about it, the less I like the idea. To begin with, I was impressed by the idea of sticking so many PCs in one rack, but the more I thought about it and used it, the more I became convinced that VMs are the right way to go.

With gigabit for the iSCSI and less contention on the NAS/SAN, the RPS may come close to a good VM, but I still can't see any reason why you'd want an RPS over a VM.

Andy
18-06-2009, 13:59
The RPS series was designed for personal use and testing, not for serious uptime critical or speed critical applications. It was designed to be the cheapest and closest thing to a real dedicated server, nothing more.

Ashley
18-06-2009, 13:57
Quote Originally Posted by over9000
Sorry mate you are trying to turn a serious issue into a joke.

The RPS is not a "toy", and it is not advertised as such.
Well it shouldn't be considered for serious web applications.

over9000
18-06-2009, 13:50
Sorry mate you are trying to turn a serious issue into a joke.

The RPS is not a "toy", and it is not advertised as such.

freshwire
18-06-2009, 03:34
It's a toy! I love to play with my toys vroom vrooooom!

Ashley
18-06-2009, 01:04
Quote Originally Posted by over9000
So why was this put in place if for nothing else other than to make money???? :3
Because you could build a very good data processing cloud out of £9.99 RPS's with a larger server acting as the NAS. I wouldn't mind paying £10 a month for an extra 1.6ghz.

over9000
18-06-2009, 00:55
I understand that, the network works great but the thing is I signed up for a years contract and it has now been changed significantly to mine and other RPS users disadvantage. Fair enough if I signed and paid now, but when you sign up for something the package normally stays as it is when you signed up, which is how it should be. Why was this brought in anyway? It couldn't have been congestion because there didn't seem to be any problem with this sort of thing when I signed up and for a long time afterwards, and then I saw it in the forums and it's true! My disk speed has now been changed significantly from when I originally signed up and I am expected to pay to get it back! lol xD

So why was this put in place if for nothing else other than to make money???? :3

derchris
17-06-2009, 18:50
Quote Originally Posted by over9000
HURR DURR DERP DERP (my laugh)

Yes I am, but having 100 megabit on a test file is useless to me.
But that proves that there are no issues with internal network performance

ruperthair
17-06-2009, 15:29
As *everyone* has tried to point out: The iSCSI 'disk' on the RPS is not fast. It was the limiting factor in the file transfer between your and your friend's RPSes. It will be the limiting factor in any test that uses the 'disk'.

I don't think that 1MB/s is acceptable performance for the root 'disk' so I switched to a dedicated server. If you want more than 1MB/s from/to your disk, then I would switch to a dedicated server or a virtual machine from some other provider (OVH do not sell individual VMs).

freshwire
17-06-2009, 15:26
Lag was never an issue before these access speed changes came into place. Thats what I said and the post got deleted. Why?
There is no limit for you. the 1MB/s for standard is simply saying the minimum guaranteed speed you can expect. There was no sudden limit applied. You and your friend should come together and buy the smallest kimsufi as if your service requires more guaranteed disk access then you need your own hard disks. As I see it OVH have not broken any ToS. Setting a minimum guaranteed transfer speed for clients in the same boat as you cannot be taken as limiting your speed in any way.

Anyway. Think about the kimsufi.

over9000
17-06-2009, 14:28
Quote Originally Posted by ruperthair
Looks like you're getting 100mbit/s to me.
HURR DURR DERP DERP (my laugh)

Yes I am, but having 100 megabit on a test file is useless to me.

ruperthair
17-06-2009, 14:23
Looks like you're getting 100mbit/s to me.

over9000
17-06-2009, 14:06
wget ftp://ftp.ovh.net/test.bin -O /dev/null
--15:09:46-- ftp://ftp.ovh.net/test.bin
=> `/dev/null'
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 11.2M/s in 9.0s

15:09:55 (11.1 MB/s) - `/dev/null' saved [104857600]

over9000
17-06-2009, 14:03
Quote Originally Posted by monkey56657
I still going with the added lag when using 2 x of iSCSI disks. Even if the speed at one end can do a few MB/s the doubled lag with 2 networks disks is sure to have an effect on that number? All the test results so far still comply with this ^

Why do my posts keep getting removed or edited?

Lag was never an issue before these access speed changes came into place. Thats what I said and the post got deleted. Why?

marks
17-06-2009, 12:17
?!?!?!?!
no worries...I'll be back tomorrow ;-)
What it's true is that a quick and reliable system to check speeds (both incoming and outgoing) would be very helpful. I'll see what I can do about it.
I can also tell you that we cannot run these tests ourselves.....not for every and each customer that comes to us with doubts about speeds (which normally end up being problems with the other server, overheads placed for the software in use, the protocol, ....)

Seedbox Paradis
17-06-2009, 11:59
Quote Originally Posted by Marks
we'll have to start somewhere. Do you want to look at it or not? it's just a couple of minutes to do the simplest test......
Yes its a couple of minutes to run a download test, but you might as well show him how to test his upload too, seeing as by the time he gets around to reading your post you'll probably be at home enjoying the rest of your day. So a quick test ends up being a slow 24 hour wait for another suggestion...

marks
17-06-2009, 11:57
we'll have to start somewhere. Do you want to look at it or not? it's just a couple of minutes to do the simplest test......

Seedbox Paradis
17-06-2009, 11:25
Quote Originally Posted by Marks
regarding the conversation between Adny and over9000: the T&C are written to take into account the worst most extreme cases, but I don't think they have anything to do with the speed problem with your server.

As I said before, it might be that, in specific times when the network is overloaded, the servers with guaranteed bandwidth take priority over RPS, but that would be only in specific times and mainly OVH to Internet.



As far as I understood, that's not your problem



So I would like to know more about the problem so we can look at it and understand it properly.

When you're testing between 2 servers, and you find a problem, this problem could be in either end.

Could you post here the output of the following command, which is downloading from an internal OVH FTP server:

wget ftp://ftp.ovh.net/test.bin -O /dev/null

Run this from your machine. If it does show a speed problem, then run it again but from the rescue mode. If the output shows slow speeds, then I would definitely agree that there is a problem on the machine. There can be some reason why we limit the speed: it could be that we protect the system if there was a DDoS attack which will slow the bandwidth or the monthly bandwidth has been over 100Mbps for quite a long period of time.

But honestly, I would be surprise if those commands show any problem.

If they don't show any problem, but you still experience low speeds connecting to your friend's server at OVH, then you would have ruled out several possible causes for this issue.

Please, post here the outputs of those commands, because after so much talk you haven't shown as proofs on where the problem is.

Thanks a lot, guys
This will only test the RPS' download connection, not the upload. Time to start thinking outside the box

marks
17-06-2009, 10:20
regarding the conversation between Adny and over9000: the T&C are written to take into account the worst most extreme cases, but I don't think they have anything to do with the speed problem with your server.

As I said before, it might be that, in specific times when the network is overloaded, the servers with guaranteed bandwidth take priority over RPS, but that would be only in specific times and mainly OVH to Internet.



As far as I understood, that's not your problem

For example, I can download a file at 2400 kilobytes per second from my RPS to my home, but the same between servers at OVH occurs at 1024 kilobytes per second.

I find this strange as the data is obviously still being read from the same disk as when it is transferred OVH to OVH
So I would like to know more about the problem so we can look at it and understand it properly.

When you're testing between 2 servers, and you find a problem, this problem could be in either end.

Could you post here the output of the following command, which is downloading from an internal OVH FTP server:

wget ftp://ftp.ovh.net/test.bin -O /dev/null

Run this from your machine. If it does show a speed problem, then run it again but from the rescue mode. If the output shows slow speeds, then I would definitely agree that there is a problem on the machine. There can be some reason why we limit the speed: it could be that we protect the system if there was a DDoS attack which will slow the bandwidth or the monthly bandwidth has been over 100Mbps for quite a long period of time.

But honestly, I would be surprise if those commands show any problem.

If they don't show any problem, but you still experience low speeds connecting to your friend's server at OVH, then you would have ruled out several possible causes for this issue.

Please, post here the outputs of those commands, because after so much talk you haven't shown as proofs on where the problem is.

Thanks a lot, guys

freshwire
17-06-2009, 03:42
I still going with the added lag when using 2 x of iSCSI disks. Even if the speed at one end can do a few MB/s the doubled lag with 2 networks disks is sure to have an effect on that number? All the test results so far still comply with this ^

Myatu
17-06-2009, 02:45
Well, the problem seems to be TCP/IP communication between your server at OVH, and a friend's server at OVH -right? However, your connection to the iSCSI disk seems to be fine - am I still right?

So wouldn't it be possible to eliminate the TCP/IP bottleneck between your server and your friend, by allowing your friend to directly mount your iSCSI LUN on his/her own machine? If it's a dedicated machine he/she is using, open-iscsi would be an option for example.

over9000
17-06-2009, 02:21
Sorry I dont get you.

Could you elaborate?

Myatu
17-06-2009, 02:17
Here's a silly thought: Wouldn't it be possible to simply mount the iSCSI on the 'other' OVH server with the credentials from the RPS?

Andy
17-06-2009, 02:02
Remember torrent clients do use caching so its quite easy to see the full download speed while its storing to the cache. It may very well be writing to the disk much slower, and the only way you'll know is if you use the likes of utorrent which has caching info and the graphs/stats to show what is being written to the disk and how fast.

I'd never be able to retain customers since I'm too honest I hate lieing. Lieing loses customers, not gains them. If people understand what is going on they're more likely to stick with something with the knowledge of how it works then guessing all the time and getting a sporadic service and no knowledge of why. Basic principles really.

E.G. 1Gbps unmetered!!! Customer comes along and gets 50Mbps tops, then finds out from someone else that 1Gbps is internal only except at 1am-2am when its full speed to the internet. All other times are 50Mbps.

That would soon lose customers when the word gets around. Its best to tell people they have a 1Gbps port, usable at max between 1-2am, but all other times is 50Mbps

Lieing never got anyone far in this world, and it sure won't start changing now

over9000
17-06-2009, 00:56
Well if you did I don't think you'd be doing much for customer retention with the line about the T&C's.

You have to admit that it is very misleading now with the way that the bandwidth is advertised.

For one, 10 megabits is far too slow IMHO for an internal server transfer.

I tested tonight by torrenting a linux distro and I was able to attain a speed of roughly 7,500 kilobytes per second throughout the entire download, which just baffles me further as this is being written to the disk.

The attractive pricing of the RPS has now been made irrelevant by the fact that you have to pay a premium for the ability to be able to just write to your disk at a decent speed. It now works out that you are better off price-wise to get one of the cheaper dedis or kimsufis on offer. Thats what I'll be doing when my contract for the RPS is up.

I think it would be much fairer if the SAN access speeds were split on to tiers, for example pay for 100 megabit to the disk, or get 50 megabit half speed access if you don't.

Can anyone from the staff team actually elaborate on these discrepancies with internal/external transfer speeds?

Andy
16-06-2009, 23:33
You make a very good point there. But remember its a minimum speed, not a maximum. However there must be some reason an OVH-OVH transfer makes it run at the minimum of 1MB/s rather than going upto 100Mbps.

As for working for OVH, I would, if a) They had a job opening for me that I was qualified for (I don't speak or read French, nor do I use Linux (and hope I never do)), b) They were a little closer to my home I don't fancy moving to London, its a bit far.

over9000
16-06-2009, 23:04
For example, I can download a file at 2400 kilobytes per second from my RPS to my home, but the same between servers at OVH occurs at 1024 kilobytes per second.

I find this strange as the data is obviously still being read from the same disk as when it is transferred OVH to OVH.

over9000
16-06-2009, 22:55
The terms also state they can be changed at any time, and you accepted that.
Andy, if you don't work for them, you should.

The changes have significantly disadvanted many people that have RPS. The changes are very big indeed.

It's just a get out clause so that companies like OVH can make these changes, or any change that they want, without the customer being able to do anything about it!

The question still has not been answered though; how is it that I can download stuff from my RPS (that is not in RAM ) to my home, faster than I can transfer it OVH to OVH. That really is baffling.

freshwire
16-06-2009, 13:26
Also there was never any speed information provided before about the network disks. It's taken as understood that network disks are gonna be slower than physical disks. As many people have said (including myself) try transferring from a faster mirror (such as the debian germany mirror) to the rps RAM. You can see the connection speed performing well then.

Andy
16-06-2009, 13:06
Quote Originally Posted by over9000
So if this wasn't the case when I signed up, then why have the terms of my account been changed now? That's a bit of a rip don't you think???
The terms also state they can be changed at any time, and you accepted that.

Remember, 1MB/s is MINIMUM, not the maximum. If the filer is not under strain, you'll get more bandwidth than that up to your 100Mbps port maximum, but if it is under strain, that's the minimum you'll get.

marks
16-06-2009, 09:57
Your terms probably haven't changed, but the terms on the network bandwidth for RPS is that the bandwidth is not guaranteed. That means that, if our network is not under strain, you'll get 100Mbps. But if there is a high volume of traffic at a certain moment, the servers with guaranteed traffic will have priority.

In any case, I would like you to post back the output of the following command, let's see if things have changed:
wget ftp://cdimage.debian.org/debian-cd/5...i386-DVD-5.iso -O /dev/null

thanks

over9000
16-06-2009, 00:20
Quote Originally Posted by Andy
They were not limited a month ago or before then.
So if this wasn't the case when I signed up, then why have the terms of my account been changed now? That's a bit of a rip don't you think???

freshwire
15-06-2009, 23:42
Quote Originally Posted by over9000
Sorry Monkey, thats a completely different subject altogether....
I think it has great relevence here.

Try using the disk on one RPS to the ram on the other... im sure it will prove to be faster speeds.

Andy
15-06-2009, 23:34
They were not limited a month ago or before then.

over9000
15-06-2009, 23:23
Sorry Monkey, thats a completely different subject altogether.....

Is it me, or were the transfer speeds for disk access not limited as they are now a few months ago?

freshwire
15-06-2009, 23:19
Consider that the hard drive's access time increases lag on the connection.

If you have 2 rps involved its 2x the lag. If you have just RPS and you the lag is reduced. It doesn't matter if they are on different disk arrays the lag both ends will still have an effect.

over9000
15-06-2009, 22:41
It still doesn't explain why I can download from my server at my connection max ie 20 megabit, when this data is surely still coming from the SAN?? But not within OVH. And I am sure that wasn't the case when I signed up in November....

Seedbox Paradis
15-06-2009, 21:42
As much as I like the concept of having a cheap server, I don't think the RPS series will really last, at least for me, they are wayyy too unstable and having an actual dedicated server for £20 is good enough for me

freshwire
15-06-2009, 21:00
Yes as oles said the 1MB/s is between the disks and server. So you can easily transfer out at 100Mb/s if you use data stored in ram or generated on the fly.

oles@ovh.net
15-06-2009, 17:38
over9000 a écrit:
>
> Well my point is that the servers should not be advertied as having 100
> megabit OVH to OVH bandwidth when this is not the case.


there is 100Mbps between OVH/OVH. you can test with with
-O /dev/null
but you have no 100Mbps to the iSCSI hard disk. 1Mo/sec
garanteed.


oles@ovh.net
15-06-2009, 17:36
over9000 a écrit:
>
> Hi,
>
> I have been transferring some files between my RPS and a friends. At


try

wget http://.... -O /dev/null




fozl
15-06-2009, 17:01
Quote Originally Posted by over9000
Sorry mate, you've wound me up a bit with your reply in that thread.

What has that thread got to do with the issues with transfer speed in this thread? I have already said that downloading to my home machine works fine, to the point that it is faster than an OVH to OVH transfer.

I don't want to post my NIC-handle on the open forum.
Yes, it's for this reason that I advise in both cases to contact us by email. It's more dangerous to publish your IP or server name then the nic though, but all the same why present a target for bruters.

over9000
15-06-2009, 14:29
Well my point is that the servers should not be advertied as having 100 megabit OVH to OVH bandwidth when this is not the case.

I dont think it makes much sense to be able to transfer files to my pc faster than I can transfer from ovh to ovh. You must admit that is quite strange indeed.

ruperthair
15-06-2009, 14:23
Quote Originally Posted by over9000
So you get a 100 megabit connection that is effectively useless unless you pay some sort of premium to be able to transfer files at full speed between servers?
As I understand it (not being an OVH employee), the contention is at the filer rather than at the switch port. I would suggest that you and your friend pool your money and rent a kimsufi.

over9000
15-06-2009, 14:07
Hmm interesting.

So you get a 100 megabit connection that is effectively useless unless you pay some sort of premium to be able to transfer files at full speed between servers?

I really don't get that. When I signed up the RPS was and still is advertised as having 100 megabit OVH to OVH bandwidth, when in reality it is nowhere near that at all. When did that come in? As I am sure that this was not the case not so long ago when transfers between servers were faster.

Is this just a way to milk just a little bit more money out of the customers? It's a poor tactic to say the least, to advertise the bandwidth as 100 megabit, when you have to pay extra to be able to achieve those speeds.

ruperthair
15-06-2009, 14:01
Quote Originally Posted by over9000
Why are these transfers happening so slowly? I get more speed when I download the file to my PC at home! Surely that can't be right that I can transfer to home faster than I can transfer from one OVH box to another?
Also see this post where Octave (the big boss) says:

Quote Originally Posted by oles@ovh.net
Following the evolution on the quality of iSCSI disks and internal tests, we think we can guarantee you the flow to our storage infrastructures. We should be able to get these performances:

- standard 1MB/sec (between 6Mbps and 10Mbps)
- premium 4MB/sec (between 18Mbps and 28Mbps)
- business 10MB/sec (between 50Mbps and 90Mbps)
So 1MB/s, although *very* poor, is actually within their 'standard' package.

over9000
15-06-2009, 13:57
Sorry mate, you've wound me up a bit with your reply in that thread.

What has that thread got to do with the issues with transfer speed in this thread? I have already said that downloading to my home machine works fine, to the point that it is faster than an OVH to OVH transfer.

I don't want to post my NIC-handle on the open forum.

fozl
15-06-2009, 13:43
I reffer the honorable gentlemen to the response I give on the other thread: http://forum.ovh.co.uk/showthread.php?t=2255

over9000
15-06-2009, 13:37
Hi,

I have been transferring some files between my RPS and a friends. At first they were very fast, as would be expected for an OVH server to server transfer.

Last few times have been almost painfully slow. Here is a transfer I just completed:

--14:38:16-- http://*.co.uk/VAHA.tgz
Resolving *.co.uk... *
Connecting to *.co.uk|*|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 154910720 (148M) [application/x-gzip]
Saving to: `VAHA.tgz'

99% [================================================== ========================= 100%[================================================== ========================= ===============================>] 154,910,720 999K/s in 2m 18s

14:40:35 (1.07 MB/s) - `VAHA.tgz' saved [154910720/154910720]
Why are these transfers happening so slowly? I get more speed when I download the file to my PC at home! Surely that can't be right that I can transfer to home faster than I can transfer from one OVH box to another?

Anyone care to help me out on this one?