|
#1
|
|||
|
|||
|
Linux Vs Win execution speed.
I have an application build in C++, which is portable on Win and Linux. It's a communication node between other two applications, and it's using UDP as streaming.
The problem is that the entire installation is running faster when this node runs on Windows, and much slower when it's on Linux. All it has to do, is to listen on a UDP port, and sent received data on an other UPD port. But it's running tree or four time slower on Linux, I can't figure it out why. Weird thing is when this node is running on Linux Virtual Machine (Ubuntu) which is hosted by a Windows machine, it's running as fast as it would be on a Windows box natively. So, I'm thinking that it's a network configuration problem... Does anyone know what would be the reason. Anyone found a similar behaviour? Thanks. |
|
#2
|
|||
|
|||
|
The possibilities are pretty wide open given the information you put out. When you run "on linux" what all is competing for the CPU? Is the linux machine and Windows machine the same machine "dual-booted"? If not, what are the hardware resource differences?
|
|
#3
|
|||
|
|||
|
Yeah, it's a dual boot, both operating systems are running on same machines. I've been test them on serveral other machines, with different hw, but same thing. On Linux, it's running way too slow.
My frustration is with the Virtual Machine. How is that possible? My opinion is that the Linux drivers running on VM is forwarding the network packages on host machine, which is Windows. So that's why it's running faster. |
|
#4
|
|||
|
|||
|
Ok. so dual boot means the hardware resources are the same.
Yes, the VM ultimately uses Windows to do its work. I see three possibilities: 1) The Linux boot has a lot of programs running that is eating up your CPU. If you are using the same linux install on the other machines, perhaps you should check exactly what you are installing and why. (e.g., if you are running a sql server just because it is neat...) 2) You have driver problems. 3) Your networking is set up wrong on the linux install. I know, these are all pretty obvious. When you say that you are using "UDP as streaming" that doesn't make a lot of sense to me. UDP is for discrete messages, TCP is for streaming data. |
|
#5
|
|||
|
|||
|
Stream just means constant flow of data, really. We "stream" video with UDP and if we lose frames the format we use recovers from it and keeps going. We can't afford to re-send frames and get behind, so we use UDP and dropped packets are just lost. If the comms go out, the video does too, or flickers for a frame now and then, but its better than watching what happened 30 seconds ago when you are trying to see the present.
If the VM linux works and the booted one does not, is that the same linux (just using the same install in a VM instead of booting) ?? If so, the problem is likely driver problems. It still could be the setup, I am not sure exactly where the VM interrupts the low level OS commands, for sure the VM is using the windows drivers and basic networking setup but some of the linux networking setup is probably still active. If they are the same install, I would start here, maybe dig into the documentation or online stuff to see where the VM is taking over from the virutal OS to get it to work on real hardware and through the real OS. If its driver level only, thats probably your issue. If its network level too, you may not be able to isolate the issue rapidly. |
![]() |
| Bookmarks |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| app runs under win but not linux | polaris | Java | 0 | 11-14-2006 11:33 AM |
| REAL Software Announces Linux Strategy - Enables Migration of VB Apps to Linux | Gwen Smith | vb.announcements | 0 | 07-21-2003 03:17 PM |
| My view of the world | Kevin Moore | .NET | 55 | 02-27-2002 04:06 PM |
| LINUX's achilles heel | tamizh selvan | Open Source | 31 | 02-19-2001 05:24 PM |
| The Linux band wagon | chris p | authorevents.matthew.stones | 1 | 06-29-2000 05:10 AM |