send and recv are cpu intensive?

I am using Sockets in C# and have gotten to the point where I want to send a file through the connection. I have the server send a file to the client by reading a chunk of the file and sending that data, and it keeps doing this until the entire file is sent. Than on the client side it just collects and writes the data to the file until it gets all of the data.

However the problem is that this uses 100% cpu usage. The 100% is split between 3 processors, the server, client, and system (server and client are ran on the same computer). I have tried different buffer sizes including 256 bytes, 1024 bytes, 8096 bytes, and even 25000 bytes and they all give the same cpu usage. I have determined that it is indeed the send and recv commands that do it and not the file reading and writing.

So does anyone have a solution for this?

Your code may be what is causing the 100% CPU - we'd have to see to be sure.

However, if your sever and client are running on the same PC, and you're talking over localhost, you might get that behavior. Try testing on different PCs - do you still get 100% CPU?
(And, what is the speed of your CPU?)

Okay I tested on 2 different computers through the internet. The CPU usage for both computers was 0%. I was not able to test on 2 computers through lan sence our other computer is currently broken but I think this test is enough to say that you are right. Thanks for the idea to actually test the application in a real way.

Also just for uneeded reference my CPU is a 2.08Ghz AMD. Could be why I got horible results, maybe a faster CPU would yeild less than 100% CPU usage.

But how long is it at 100% for?

If there is work to do, and there is nothing blocking it, getting the whole job done in 2 seconds is preferable to say a couple of minutes with minimal CPU utilisation.

Quote:

---

Originally Posted by Rune Hunter

Okay I tested on 2 different computers through the internet. The CPU usage for both computers was 0%. I was not able to test on 2 computers through lan sence our other computer is currently broken but I think this test is enough to say that you are right. Thanks for the idea to actually test the application in a real way.

Also just for uneeded reference my CPU is a 2.08Ghz AMD. Could be why I got horible results, maybe a faster CPU would yeild less than 100% CPU usage.

---

If you are communicating within your own machine (localhost) there is a good chance that ANY speed processor will use 100% CPU since all it's doing read and write to memory buffers and passing those buffers back and forth between differnet parts in your system - and that uses CPU time, and if there's nothing else blocking the processing, then it will use 100% - and ther's nothing wrong with using 100% CPU time for some time, as long as it's not "permanent".

As Salem said, getting a job done in 2 seconds at 100% cpu-load is fine. Reducing the CPU-load would involve something like putting delays in your code, and whilst that would reduce the CPU-load, it really doesn't change the overall amount of CPU used to transfer the data, but it does increase the time it takes to get the data across.

--
Mats

If you're using non-blocking sockets, you may want to use some Sleep() functions here and there.

All sleep would do would be to spread the work out.
2 seconds at 100% or 20 seconds at 10% - it's still the same amount of work being done, just spread out more.

not if there's no data on a non-blocking socket.

or so I hear.

Quote:

---

Originally Posted by robwhit

not if there's no data on a non-blocking socket.

or so I hear.

---

But if that was the case, the CPU usage wouldn't be going down when the same setup is running over a network, right?

--
Mats

oh yeah, forgot about that.

well it is staying at 100% cpu usage until the file is transfered. With my current setup I can get anywhere from 5000 to 23000 kb/sec. So what you guys are saying seems to be correct. I did put a Sleep(1) in the client receive and the cpu usage went downt o 0%. Of course the speed went down to 100-200 kb/sec so not the best choice. I am now actually quite happy with 100% usage cause what everyone said is very correct, I just never thought about it that way.

Thanks for all of your help!

Sleep() will still cause yoru program to use 100% of the CPU if no other threads have anything to do. Even non-blocking calls will use 100% fo the CPU on localhost connections becuase you are actually using 100% fo the cpu, its nto a glitch. Your transfer rate is literally as fast as you can pass the data across the stack. A truer indication of how much cpu will be needed in the real world would be to artificially limit the upload rate and make the code blocking. In reality you may want to make the code blockign anyway for several reasons.

Quote:

---

Originally Posted by Rune Hunter

However the problem is that this uses 100% cpu usage. The 100% is split between 3 processors, the server, client, and system (server and client are ran on the same computer). I have tried different buffer sizes including 256 bytes, 1024 bytes, 8096 bytes, and even 25000 bytes and they all give the same cpu usage. I have determined that it is indeed the send and recv commands that do it and not the file reading and writing.

---

Well yeah. It should be obvious that this is what will happen. If both server and client are on the same machine, there is no network to contend with. This means data can flow as quickly as the machine can process it. This means the machine maxes out. There's no mystery here.

If the CPU was NOT at 100%, that means there would be some "waiting" happening somewhere. Exactly where would that waiting occur? There's no reason to wait at all -- the communication is completely local.

Quote:

---

Originally Posted by abachler

Sleep() will still cause yoru program to use 100% of the CPU if no other threads have anything to do.

---

I think you are confusing sleep with yield or some such. Sleep will make the program stop for as long as you tell it to sleep (e.g. 1 millisecond, a second or whatever). During this time, this particular process will use 0% of the CPU-time (as it's on the "waiting queue", none of the processor usage will be for this process, until the sleep-time is up).

Admittedly, if there's no other process to use the CPU-time, all you're doing is pretty much WASTE wall-clock-time, of course. The system isn't going to be "tired" by using the CPU 100%. [It may get a tiny bit warmer, of course].

--
Mats

What I meant was Sleep(0);, which merely yields the processor to another waiting thread of the same or higher priority. Sorry for the confusion.