[trevorcobb]

I can scp (using fugu) from my Macbook Pro to the ATV over ethernet at about 8MB/sec. Even over wireless from my Macbook Pro to the ATV I am still getting about 6MB/sec.

But if I try and do the thing from any Win7 installation, I can not get more than 1.5-2MB/sec. Whether it's from my Macbook Pro running Win7 natively under bootcamp, or whether it's from my Macbook Pro running Win7 under Parallels Desktop, or from my Media Server running Win7. All instances of Win7 are Professional x64 version.

This didn't start being an issue for me until maybe 3-4 weeks ago when *EVERYTHING* I tried to stream in higher resolution than SD started wanting to buffer every 1 or 2 minutes on XBMC. I installed Ubuntu on my ATV and I get the same result. Any file transfer via SCP or streaming over SMB and I can't break through the 2MB/sec invisible ceiling that is there.

So frustrated...

http://social.technet.microsoft.com/Foru...cb831c8575

[sezb51]

What about using ftp instead of sftp ?

http://wiki.awkwardtv.org/wiki/Enable_FTP_Server

If this does not improve, you may want to try disabling on Win7 the auto-tuning:

1.Open up an elevated command prompt.
2.Enter the following command to disable auto-tuning
netsh interface tcp set global autotuninglevel=disabled

[trevorcobb]

the transfer protocol doesn't matter. it's at a more underlying level of network communication.

[sezb51]

Protocols do matter because the cpu on the ATV is limited, therefore a non-secure protocol like ftp/cp instead of sftp/scp allow more bandwidth. The packets of the secure protocols have to go through cpu for beeing encrypted/decripted and this slow down performance...

Said that, it could be that in your environment there are other issues that could be network or OS related.
For the first case (network) probably sniffing the traffic (wireshark) could reveal retransmissions due damaged cables or misconfigured switches (ie: speed/duplex mismatch) - here a crossover cable could be a good debugging starting point.
For the second (OS) maybe some error logs are present on both ATV and/or Win7.

[trevorcobb]

Protocols do matter because the cpu on the ATV is limited, therefore a non-secure protocol like ftp/cp instead of sftp/scp allow more bandwidth. The packets of the secure protocols have to go through cpu for beeing encrypted/decripted and this slow down performance...

Said that, it could be that in your environment there are other issues that could be network or OS related.
For the first case (network) probably sniffing the traffic (wireshark) could reveal retransmissions due damaged cables or misconfigured switches (ie: speed/duplex mismatch) - here a crossover cable could be a good debugging starting point.
For the second (OS) maybe some error logs are present on both ATV and/or Win7.

I have taken your suggestion to use a crossover cable, to eliminate the possibility of a bad cable, or the switch built into my router being broken. To no avail. I have the exact same results whether connecting through one client to another via switch or via crossover.

On to the second (OS) segment troubleshooting you recommended:

- What should I be looking for in my XBMC logs?

- Where does Windows 7 keep network error logs?

*****

P.S. In case you didn't read the link in my first post, here is my network setup:

I have a Linksys WRT610N router with most recent firmware.

Clients:

A) Windows 7 Pro x64 Desktop PC acting as media server, connected to router over Gigabit Ethernet.

B) Windows 7 Pro x64 on Macbook Pro running natively via bootcamp, GigabitE

C) Mac OSX Snow Leopard 10.6.4 on same Macbook Pro, GigabitE

D) Same Windows 7 Pro x64 running on Macbook Pro but under Parallels Desktop v5, GigabitE

E) AppleTV hacked to run XBMC under AppleTV OS as well as Ubuntu 8.04., 100Mbit Eter

A-->E via WinSCP = 1.8-2.2MB/sec ~ 16 megabits/sec

B-->E via WinSCp = 1.8-2.2MB/sec

C-->E via Fugu SCP = 8MB/sec ~ 64 megabits/sec

D-->E via WinSCP = 1.8-2.2MB/sec (CRAZY because it's the same computer 5 seconds earlier I was getting 8MB/sec under OSX)

A-->C via SMB = 3MB/sec

A-->C via Microsoft Remote Desktop Client = 9MB/sec

[trevorcobb]

Protocols do matter because the cpu on the ATV is limited, therefore a non-secure protocol like ftp/cp instead of sftp/scp allow more bandwidth. The packets of the secure protocols have to go through cpu for beeing encrypted/decripted and this slow down performance...

i understand about extra CPU overhead using an encrypted protocol vs. non-encrypted, but that doesn't explain why I would get higher transfer rates to/from the the appletv using the same client machine, same exact protocol (SSH/SCP), but different OS (win7 vs OSX10.6.4)?

[davilla]

i understand about extra CPU overhead using an encrypted protocol vs. non-encrypted, but that doesn't explain why I would get higher transfer rates to/from the the appletv using the same client machine, same exact protocol (SSH/SCP), but different OS (win7 vs OSX10.6.4)?

Perhaps windows is also virus checking incoming files ?

[Sam.Nazarko]

Check a couple of things out if it's bothering you that much. I'm going to narrow it down to:

1. Firewall incorrectly configured
2. Network latency - your using Windows 7 - try disabling auto-tuning. Also, run a ping command from your Windows box to aTV and see if your getting a high latency.
4. Network card driver issue. Are you running 64-bit - this can cause problems for drivers. What card model do you have

[trevorcobb]

1) firewall turned off
2) ping latency is the same on Win7 vs OSX10.6.4 when pinging ATV, and vice versa. all very low ms ping times.
3) ??
4) Network card driver hasn't changed in the last 6 months. Slow transfer problem only started 30 days ago. Plus I have the same issue from two separate Win7 machines (desktop PC and Macbook Pro, completely different network cards, same problem)

[Sam.Nazarko]

Sorry about Number 3, I can't count hehe.

Have you considered defragging the drives? Try re-creating the SMB share in Windows by disabling it and re-enabling it. I've a few more suggestions but I'll hold off until you can confirm you've still got a problem.

You don't have any GPO QoS settings active right?

Network Card model, router model and model of any switch or network devices crossing between might help

Quite strange this is acting up for you

[ral67]

use ftp - its worth it

from Win7 I get at least twice the performance compared to winscp

it also depends on the disk and file system

internal disk with HFS+ gets almost 100BaseT wire-speed

external USB disk with FAT32 was much slower, now formatted with HFS+ I also get 5-10 MB/s

[Sam.Nazarko]

use ftp - its worth it

from Win7 I get at least twice the performance compared to winscp

it also depends on the disk and file system

internal disk with HFS+ gets almost 100BaseT wire-speed

external USB disk with FAT32 was much slower, now formatted with HFS+ I also get 5-10 MB/s

Lol WinSCP is not a protocol, I presume you mean you get faster speeds using FTP vs SFTP. But WinSCP does both.

No one uses FAT32 these days surely? The FS corrupts, doesn't have permissions handling and files are limited to 4GB. I use NTFS and I get throughputs that are faster than Fast Ethernet. WD Caviar Black drives in the server (SATA II) easily get 500Mbits (~65MB/s)

[ral67]

yes I meant scp as did the OP

how do you get NTFS writing on an ATV ?

the standard driver is read-only for all I know

[Sam.Nazarko]

Aren't you just streaming from the network? I think NTFS.kext gave we R/W though.

[ral67]

Aren't you just streaming from the network? I think NTFS.kext gave we R/W though.

no - its definitely readonly

I think NTFS write only came with MacOS 10.5 natively