On 9/20/07, Bruce Cole <[EMAIL PROTECTED]> wrote:
> Yes, that *was* the common recommendation. But recently I narrowed down the
> realtek performance problem most commonly seen with samba (but also applicable
> to other TCP applications), and I also narrowed down the fix as well.
>
> The current f
On 9/19/07, Bill Fink <[EMAIL PROTECTED]> wrote:
> Just my personal opinion, but unless you want to do more testing,
> since you now seem to have a working setup, I would tend to leave
> it the way it is.
Quite sensible, yes. Performance even seems to be good - I am getting
40-40MBps reads and 24-2
Well,
the issue seems to have gone away as of this morning, but I am
somewhat unsure as to why.
Placement of some things were modified so as to allow shorter cables.
Now there are 3' CAT6 cables everywhere except for the 15' cable
between the two switches. All the cables are new, high quality
'test
This is the latest ethtool -S :
beehive:~# ethtool -S eth4
NIC statistics:
rx_packets: 33491526
tx_packets: 41410384
rx_bytes: 28384277429
tx_bytes: 46178788616
rx_broadcast: 3144
tx_broadcast: 2068
rx_multicast: 79
tx_multicast: 0
rx_errors: 0
tx_e
On 9/17/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
> The statistic we were looking at _will_ increase when running in half duplex,
> but if it increases when running in full duplex might indicate a hardware
> failure. Probably you have fixed the issue with the CAT6 cable.
Uhm, 'fixed' may be prematur
> To me it suggests that your speed is not full-duplex. Check `ethtool eth0`
> output
> and see if your link is full duplex or not. also check previous kernel
> messages
> and see what the e1000 driver posted there for link speed messages (as in
> "e1000:
> Link is UP speed XXX duplex YYY")
fro
On 9/15/07, James Chapman <[EMAIL PROTECTED]> wrote:
> Are these long frames expected in your network? What is the MTU of the
> transmitting clients? Perhaps this might explain why reads work (because
> data is coming from the Linux box so the packets have smaller MTU) while
> writes cause delays o
> >>> tx_deferred_ok: 486
>
> this one I wonder about, and might cause delays, I'll have to look up what it
> exactly could implicate though.
Please do and let me know. samba 3.0.26 helped, but the issue is still there.
> those are not "long frames" but the number of bytes the hardware counte
I also upgraded to samba-3.0.26-1 and so far the problem seems
significantly less frequent and limited, unfortunately, to the
'silent' corruption. I am still running with HW checksumming off, with
a new cable (cat6, even though it's 50cm long, so I could probably be
running chicken wire), on the or
On 9/15/07, Bill Fink <[EMAIL PROTECTED]> wrote:
> Would it be worth a shot to try disabling the receiver hardware
> checksumming (ethtool -K ethX rx off)?
I just did, unfortunately it doesn't seem to change much.
In the various attempts, however, I seem to have improved something,
maybe. As I ment
> can you describe your setup a bit more in detail? you're writing from a linux
> client to a windows smb server? or even to a linux server? which end sees the
> connection drop? the samba server? the samba linux client?
Certainly.
I have a LAN, with two switches in a stack. There currently are 7
W
On 9/14/07, Francois Romieu <[EMAIL PROTECTED]> wrote:
> For the 8169 or the 8110, try 2.6.23-rc6 +
>
> http://www.fr.zoreil.com/people/francois/misc/20070903-2.6.23-rc5-r8169-test.patch
Thank you, I will give that a whirl also, because there are some
machine builds which will not have Intel boards
On 9/14/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
> this slowness might have been masking the issue
That is possible. However, it worked for upwards of twelve months
without an error.
> I have not yet seen other reports of this issue, and it would be interesting
> to
> see if the stack or driver i
Folks,
I've been playing with multiple gigabit ethernet drivers to get samba
3.0.25+ to work reliably. The situation is as follows.
I have a network, one of the machines on the network is a
server/firewall. It contains an Intel PRO1000 dual port PCI Express
card and runs Debian-testing.
The machine
14 matches
Mail list logo
