On Mon, 14 Aug 2006, Ben Greear wrote:
> linux-os (Dick Johnson) wrote:
>
>> No it will return FAIL (-1) or an error and 0 (the bottom of the procedure)
>> if the whole things went. It is mandatory that the whole thing goes
>> so this procedure should handle any intermediate actions.
>
> I see..I missed that part.
>
>> Upon your advice, I may try to add select() although, on a write it
>> seems to be putting in user-space something that used to be handled
>> quite well in the kernel. I don't think the user should really care
>> about the kernel internals, whether or not the kernel happens to have
>> a buffer available.
>
> Since you put it in non-blocking mode, you need the select() to throttle
> unless you want to busy spin. Whether you should have to actually put
> in in non-blocking mode or not is a different question.
>
>>> I have no idea why you need to add the MIN() logic..and that seems like
>>> something that should not be required.
>>>
>>
>> It seems that some code 'thinks' that a large buffer of data is
>> an error and won't even try to send some anymore.
>
> I have seen a problem where I can repeatedly hang a TCP connection
> when running at high speed. The tx queue is full or mostly full, and
> on the wire I only see 200kpps of duplicate acks. Can't reproduce it
> with anything other than my big complicated proprietary app, so it
> remains unfixed.
>
> I am not sure if this is related to what you see or not..but could you
> check to see if there is lots of acks on the wire when this hang happens?
I will check to see what it's doing on the wire and get back.
>
>>> Even 112kbps sucks on a decent network. What is the speed of your
>>> network, what protocol are you using, if tcp, what is the latency
>>> of your network?
>>>
>>
>>
>> The network is a single wire about 8 feet long, connecting Intel gigibit
>> links on two identical computers (crossover cable). This link is TCP.
>> For high-speed data, I use UDP and I get a higher throughput because
>> there is no handshake. Thew latency is the latency of Linux. BTW, it's
>> only a gigaBIT link, you can divide that by 8 for gigabytes. I don't
>> know the actual bit-rate on the wires, if we assume 1GHz, the byte-rate
>> is only 125,000 bytes per second. Being able to use 89.6 percent of
>> that isn't bad at all.
>
> You must be meaning to add a few more zeros to that number. If you
> are getting ~125,000,000 Bytes per second then you are doing OK.
>
ACK that!
> Ben
>
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.62 BogoMips).
New book: http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
