I know this one is a bit old, but I just got around to trying it. First, the
listed command cannot be executed by a user. It would not even work with sudo
as would normally work with *buntu. I had to 'sudo su' then run it. Have folks
noticed a difference (measurable/noticeable) since doing this?-----Original
Message-----From: "Brian Phillips" [[email protected]]date: 08/02/2009 09:48
AMTo: "atv-bootloader" Subject: Re: [atv-bootloader] Re: Slow network -
SOLVED.Note: Original message sent as attachment
------------------------------------------------------------
Find precision scales that can weigh anything. Click now!
Scale
http://tagline.excite.com/fc/FgElN1gvzpWjXwGJAC1LkPNvYUK9gflDubXFWzuHEOugqcXtvTyrh1WAHWQ/
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
For more options, visit this group at
http://groups.google.com/group/atv-bootloader?hl=en
-~----------~----~----~----~------~----~------~--~---
--- Begin Message ---
Thanks for the info. I haven't had the same problems, but I'd like my
ATV running full-bore as well, so I took your advice.
Here's the corresponding line for mythbuntu:
echo performance > /sys/devices/system/cpu/*/cpufreq/scaling_governor
On Jul 31, 9:43 pm, brteag00 <[email protected]> wrote:
> I've been bothered by this for months, and finally nailed it, so I
> thought I'd share. The (wired) ethernet connection was intolerably
> slow (100 Mbit connection with ~100-200 kbps throughput), but only in
> some circumstances. In particular, it made installing my distro
> unbearable - I had a huge pipe and it took something like 6 hours to
> download a minimal Fedora 10 distro.
>
> I finally put together a solid test case and discovered that the
> throughput actually goes UP when the processor is loaded - at 100%
> load, the throughput is exactly what I'd expect from a 100 Mb link.
>
> It turns out that the buffer in the Realtek ethernet chip is really
> small. With no load (say, filling up a video buffer), the processor
> would go to sleep (ACPI state C3), and it would take so long to wake
> back up that the buffer would fill up and packets would the lost.
> When the lost packets didn't get ACKed, the sending TCP stack would
> scale back the transmission rate. However, if the CPU was loaded
> (say, playing back that video), then it would be awake enough to
> handle the interrupt in a timely fashion and the throughput was fine.
>
> The fix is to keep the processor from going all the way into C3 sleep;
> rather, we want the kernel's idle loop just to spin on an HLT
> instruction so that it wakes back up faster. This is accomplished by
> adding "idle=halt" to the kernel boot line, either in boot_linux.sh
> (if you're using atv-boot=manual in com.apple.Boot.plist), or else in
> your grub.conf file (if you're using a real bootloader.)
>
> A related issue can be caused by the CPU's clock frequency being
> scaled back by the cpufreq governor - it's "ondemand" in most current
> distros. Changing it to "performance" ( cat performance > /sys/
> devices/system/cpu/cpu0/cpufreq) on system startup alleviates this
> problem, too.
>
> Thanks to sdavilla for an awesome project - now that this problem's
> been nailed, my ATV is a kick-ass MythTV frontend.
>
> Brian
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
For more options, visit this group at
http://groups.google.com/group/atv-bootloader?hl=en
-~----------~----~----~----~------~----~------~--~---
--- End Message ---
