Pablo,
You said it is now faster without fragmentation, so how fast is it now?
________________________________
From: Pablo de Heras Ciechomski <[email protected]>
To: Discussion of the ENet library <[email protected]>
Sent: Wednesday, August 29, 2012 5:47 AM
Subject: Re: [ENet-discuss] ENet bandwidth problems
Thanks Lee and thanks Dennis! It was fragmentation and now the
sleep command makes a difference again. Fixed.
Pablo
On Tue, Aug 28, 2012 at 4:42 PM, Lee Salzman <[email protected]> wrote:
You could try the ENET_PACKET_UNRELIABLE_FRAGMENT option if you really need
fragmentation but your packet sizes are still only a handful of multiples of
MTU.
>
>I would make the packets smaller than 1400 if you want to avoid all
>fragmentation, though, 1300ish would be safer since it leaves room for
>headers.
>
>
>On 08/29/2012 12:01 AM, Pablo de Heras Ciechomski wrote:
>
>Kind of solved,
>>Made the packets into less than 1400 bytes and now it's faster. I guess it
>>has to do with fragmentation.
>>Pablo
>>
>>
>>On Tue, Aug 28, 2012 at 10:29 PM, Pablo de Heras Ciechomski
>><[email protected] <mailto:[email protected]>> wrote:
>>
>> Hello,
>>
>> I am playing around with unreliable unordered packets in ENet and I am
>> trying to figure out why I am not transferring fast enough. My packets are
>> all around 1800 bytes and are sent continuously. I seem to get the same
>> speed on most any machine independent of wifi/Gigabit LAN/local intra-
>> process communication. This is disturbing to me as I don't understand
>> why. I am using the same loop as in the tutorial and I am getting no more
>> than 250kB/s transfer rates, when it should be around 10MB/s in the best
>> scenario. Is it due to all the packet_create calls? Is it due to some
>>internal
>> throttling? Packets don't seem to be lost so I am at loss :-)
>>
>> I changed the timer to 0 ms wait on the host loop function if that makes
>> any difference, but it doesn't seem so. Adding or removing a 5m Sleep
>> (windows function so working on the whole process) doesn't seem to make
>> any change other than making the whole system unresponsive if removed.
>> Pablo
>>
>>
>>
>>_______________________________________________
>>ENet-discuss mailing list
>>[email protected]
>>http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>_______________________________________________
>ENet-discuss mailing list
>[email protected]
>http://lists.cubik.org/mailman/listinfo/enet-discuss
>
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
