Mieze

RehabMan, on 21 May 2013 - 10:12 PM, said:

Remember how much time the SAMBA project needed to develop a SMB implementation that is suitable for serious deployment. It would be a miracle if Apple managed to get the job done within a fraction of the this time.

Mieze

RehabMan, on 21 May 2013 - 09:48 PM, said:

Because they copy packets to/from a DMA buffer and let the network stack do most of the work...

Mieze

RehabMan, on 21 May 2013 - 07:24 PM, said:

My homeserver uses a MSI B75MA-P45 (i3 3225) with an RTL8111E-VL (chipset 16).
The test machine uses an Foxconn D42s (Atom D425) with an RTL8111D (chipset 9).
The 2011 iMac and Mac mini have a Broadcom 57765.

RehabMan, on 21 May 2013 - 07:24 PM, said:

Taking all the facts into account, in particular the reports of similar problems with Apple hardware, I wouldn't call this a hardware issue. I rather think that there is a serious problem in Apple's SMB stack with regard to timing. With scatter-gather-DMA and task offload the drivers timing becomes less predictable and as my driver's architecture is very similar to the network drivers of recent Macs, its no no wonder that there are similar problems. The main difference is that Apple seems to have found a hack to get it working with their hardware.

Mieze

Hello RehabMan,

I ran some small tests with Win7 using the poor Atom copying some large files from and to the Mac server with the Realtek NIC and got a throughput between 30-50MB/sec according to the time it took to complete the transfer. That is roughly what I expected with this hardware.

Also tried to use the Win7 machine as the server with the Mac server as the client. The performance was comparable to the results I got in the other scenario described above.

Mieze

Hello RehabMan,

here is what Slice mentioned:

"See my procedures RTL8168PowerDownPHY() and RTL8168PowerUpPHY()"

Maybe it will help you to figure out what is different.

By the way I disabled EEE too and it didn't resolve the issue completely. When the Realtek chip is the client, I get stable data rates of ~75MB/sec in both directions, but when the Realtek chip is the server reads are just as fast but writes are still slow.

The funny thing is the speedup, when there is additional traffic, even to the same SMB share. I started a copy operation of a 2GB file to the SMB share and it was slow (estimated time to complete more than 4 minutes). Then I started a second copy operation of another 2GB file and now both copy operations are accelerated dramatically (estimated time to complete less than 1 minute on both).

So I guess it isn't a pure hardware issue. From my point of view it seems to be more like a timing issue of the protocol in combination with the driver.

Mieze