QTcpSocket waitForBytesWritten() is longer in Windows than Linux
-
I'am sending packets (1 packet : 1344*8 + 4 bytes) over QTcpSocket. In Windows 10.000 packets wait ~1,500 second. It takes too much time when it is compared to Linux. I wonder what caused this.
Regards ..
-
@Ayse How fast is it on Linux? Is it same machine with same network interface? You should provide more information for such comparisons.
-
It is Windows "feature". We too faced with this, do not worry. :) Just do not use the waitForXX methods at all.
My assumption is that a Linux "lies", it reports that a data transferred, but to where are transferred? To the other side? To the driver's buffer? And so on. :)
Most likelly, that a Windows reports this time is to more true than a Linux.
You can't relly on waitForBytesWritten and on this time, as all this is a hardware-drivers-specific, IMHO.
PS: You can try to calculate an overage transferring time and to compare it to your Eth bandwidth (is it ~1000Mbit? ~100Mbit? ~10Mbit? ...).
-
It is Windows "feature". We too faced with this, do not worry. :) Just do not use the waitForXX methods at all.
My assumption is that a Linux "lies", it reports that a data transferred, but to where are transferred? To the other side? To the driver's buffer? And so on. :)
Most likelly, that a Windows reports this time is to more true than a Linux.
You can't relly on waitForBytesWritten and on this time, as all this is a hardware-drivers-specific, IMHO.
PS: You can try to calculate an overage transferring time and to compare it to your Eth bandwidth (is it ~1000Mbit? ~100Mbit? ~10Mbit? ...).
-
It is Windows "feature". We too faced with this, do not worry. :) Just do not use the waitForXX methods at all.
My assumption is that a Linux "lies", it reports that a data transferred, but to where are transferred? To the other side? To the driver's buffer? And so on. :)
Most likelly, that a Windows reports this time is to more true than a Linux.
You can't relly on waitForBytesWritten and on this time, as all this is a hardware-drivers-specific, IMHO.
PS: You can try to calculate an overage transferring time and to compare it to your Eth bandwidth (is it ~1000Mbit? ~100Mbit? ~10Mbit? ...).
-
It is Windows "feature". We too faced with this, do not worry. :) Just do not use the waitForXX methods at all.
My assumption is that a Linux "lies", it reports that a data transferred, but to where are transferred? To the other side? To the driver's buffer? And so on. :)
Most likelly, that a Windows reports this time is to more true than a Linux.
You can't relly on waitForBytesWritten and on this time, as all this is a hardware-drivers-specific, IMHO.
PS: You can try to calculate an overage transferring time and to compare it to your Eth bandwidth (is it ~1000Mbit? ~100Mbit? ~10Mbit? ...).
@kuzulis said in QTcpSocket waitForBytesWritten() is longer in Windows than Linux:
My assumption is that a Linux "lies", it reports that a data transferred, but to where are transferred? To the other side? To the driver's buffer? And so on. :)
Most likelly, that a Windows reports this time is to more true than a Linux.I think you're being unfair on Linux and overly generous to Windows.
First of all, no it isn't to "the other side", it's only to the OS buffer. That is made quite clear. What the OS then does with it is another matter. If you want to know what is actually going on "on the line" you need to use WireShark under both OSes.
Secondly, @Ayse , http://doc.qt.io/qt-5/qabstractsocket.html#waitForBytesWritten
Note: This function may fail randomly on Windows. Consider using the event loop and the bytesWritten() signal if your software will run on Windows.
Doesn't give you much confidence for Windows, does it? If it can fail randomly, I wouldn't rely on it for your purposes too much....
