Re: various rants about 7-currnet on AMD64

Aryeh Friedman wrote:

>>> * Many TCP/IP stack issues
>> I *really* want to hear about this.  If there's any evidence you can
>> provide, I'm all ears.  I'm not doubting your claims, I just want to
>> know what you experienced.
>>
>> Additionally, since you didn't state what PHY and NIC are used on your
>> motherboard, it's hard for me to accept that there's IP stack problems.
>> What PHY and NIC is on the motherboard?
> 
> Have no direct physical evidence any more but see thread between me
> and kris on -questions

Don't waste your time, there was null information provided ;)

> On all versions of 7-current (i386 and amd64) I get error messages
> like this on the console all the time:
> 
> TCP: [217.230.39.58]:1145 to [67.84.39.90]:6881 tcpflags 0x18<PUSH,ACK>
> ; tcp_do_segment: FIN_WAIT_2: Received data after socket was closed, sending RST
>  and removing tcpcb
> TCP: [217.230.39.58]:1145 to [67.84.39.90]:6881 tcpflags 0x11<FIN,ACK>; syncache
> _expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spo
> ofed)
> TCP: [211.55.152.196]:55206 to [67.84.39.90]:6881 tcpflags 0x18<PUSH,ACK>; tcp_d
> o_segment: FIN_WAIT_2: Received data after socket was closed, sending RST and re
> moving tcpcb
> TCP: [211.55.152.196]:55206 to [67.84.39.90]:6881 tcpflags 0x11<FIN,ACK>; syncac
> he_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably s
> poofed)

These are informational and not necessarily indicative of a problem. 
The SYNCOOKIE ones are syn scans, for example.

>>> 7-CURRENT i386 --
>>>
>>> * Horrid performence under default kernel needed to switch to
>>> ULE/IPI_PREMEPTION/DEVICE_POLLING
>> Expand on "horrid" if you could.  I run CURRENT i386 on my home machine,
>> and I've never had any need for device polling (in fact, I've never had
>> any need for it *ever* -- the one time I tried it back in the 5.x days,
>> the system became absurdly sluggish to keyboard input, serial I/O, or
>> anything else.  Network I/O was just fine though.)
> 
> Without ULE and IPI_PREMEPTION it was slower then my p4 2.8 device
> polling I tossed in for good measure and can't tell the diff one way
> or the other.

You have to quantify "slower".  Come on, can you at least try to do 
better with your reports?  What workload did you run?  What symptoms did 
you observe?  How did you measure?  etc.

>> This argument is flawed, in my opinion.
>>
>> I think a more appropriate phrase would be: "amd64 should be recommended
>> for anyone that uses 4GB of RAM or more, and doesn't want to be hit by
>> performance penalties induced by PAE on i386".
> 
> See thread in -questions... PAE is broken for my hw.

Provide a reference.

Kris