"Walter Saegesser" wrote:
> I see there is a compiler switch
> 'LWIP_SO_RCVTIMEO', which is disabled by default. Is this the means to
> accomplish a time-out - and what would be the time - or are there other
> schemes?
If you have seen the compiler switch, you might have seen that it enables a
'
Concerns lwIP v1.3.2.
I have a TCP client in an embedded app and after I send the data I have
to wait for an answer.
netconn_write ( conn, data, size, NETCONN_NOCOPY );
TNetBuf xBuf = netconn_recv ( conn );
if ( xBuf != NULL )
{
netb
>Compared to what? 20-30% increase after moving from 1.3.2 to 1.4.0? That
>would be nice.
IMO it's quite possible. The inlined IP header checksumming could be a good
part of this depending on platform and compiler and its optimizations.
Bill
___
lwip
On 5/17/2011 10:02 AM, Jordan Dean wrote:
1.3.0 (which is still what Xilinx ships) to 1.4RC2 (although I believe I've
pulled all of the diffs between that and official 1.4). This is with
checksums offloaded, raw mode.
The fact that Xilinx hasn't upgraded is either pure laziness on their part,
1.3.0 (which is still what Xilinx ships) to 1.4RC2 (although I believe I've
pulled all of the diffs between that and official 1.4). This is with
checksums offloaded, raw mode.
The fact that Xilinx hasn't upgraded is either pure laziness on their part,
or it's much harder to get it working for s
Elad Yosef wrote:
In opt.h file It marked not to use SO_REUSEADDR.
Why and Is there any fix for it?
Because you are using an old version of lwIP. Please upgrade.
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman
On Tue, 2011-05-17 at 16:53 +0200, Thomas Richter (TCD - DE/Dresden)
wrote:
> The Wireshark analysis gives me the result: "This frame ACKs a segment
> we have not seen (lost?)"
That's odd. Can you send a copy of the packet capture so I can take a
look?
Thanks
Kieran
__
Hi Kieran,
Am 17.05.2011 16:23, schrieb Kieran Mansley:
> On Tue, 2011-05-17 at 16:12 +0200, Thomas Richter (TCD - DE/Dresden)
> wrote:
>> The next sequence by the sender is a TCP_ZeroWindowProbe sequence
>> (some
>> infos to TCP Analyze Sequence Numbers with Wireshark:
>> http://wiki.wireshark.or
On Tue, 2011-05-17 at 16:12 +0200, Thomas Richter (TCD - DE/Dresden)
wrote:
> The next sequence by the sender is a TCP_ZeroWindowProbe sequence
> (some
> infos to TCP Analyze Sequence Numbers with Wireshark:
> http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers). But lwIP
> responses not with a
Hi,
during some tests with lwIP 1.4.0 I could provoke that the WindowSize is
0. This tells the sender to stop sending.
The next sequence by the sender is a TCP_ZeroWindowProbe sequence (some
infos to TCP Analyze Sequence Numbers with Wireshark:
http://wiki.wireshark.org/TCP_Analyze_Sequence_Number
"Jordan Dean" wrote:
> it's working great (20-30% throughput
> increase
> running tcp).
Compared to what? 20-30% increase after moving from 1.3.2 to 1.4.0? That would
be nice.
Simon
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freund
I am using RAW. I didn't mess with any timer stuff, what I did do is
define NO_SYS_NO_TIMERS=1 in opt.h and that seemed to take care of any of
the weirdness with the new timer stuff. I still just call the tcp timers as
I did with the old stuff and it's working great (20-30% throughput increase
r
Jordan,
Thanks for the advice, I've upgraded from 1.3.0 to 1.3.2 and changed the
timer interrupt as per your recommendation and it no longer stops after
10mins. Porting to 1.4.0 doesn't seem quite as straightforward when using
the raw api (NO_SYS=1). I replaced the ethip_hdr in etharp.h however
13 matches
Mail list logo
