Urania

Since switching to Leopard on my server earlier this week, I have noticed that file transfers over the Ethernet LAN at work are insanely slow. I frequently synchronize files (over AFS File Sharing) over an Ethernet LAN between my server and my MacBook Pro. My MacBook Pro has been running Leopard for several months while my server was running MacOS 10.4.11 until this week. Having been happy with Leopard on my MBP, I decided to upgrade my server. Since then, file transfers between the two computers have been a royal disaster. When I initially connected I was getting speeds of up to 1.5 MB/s, but it quickly drops to 30KB/s or less. This was much less than the 10MB/s speeds I was typically seeing before upgrading my server to Leopard. I couldn’t quite figure out the pattern. It did seem the speed uploading files to my server was not as affected as downloading from my server.

Given the fact I didn’t see any file transfer issues between the two computers before upgrading the server to Leopard (MacOS 10.5.2), I suspected the issue was solely with the server (or possibly due to the communication between two computers running Leopard). On a hunch that the “self-tuning” networking heralded (quietly) on Apple’s Leopard Features page might be the problem, I tried to turn it off by tinkering with the “Advanced” settings in the Network Preference Pane. Specifically I changed the settings to look like this:

Notably, I forced the configuration to be manual (instead of “Automatic”), I set the “Speed” to “100BaseT” which is my LAN’s speed (instead of “autoselect”), and I set the “Duplex” to “full-duplex” without “flow control”. I left the “MTU” at “Standard (1500)”.

Making these changes seems to have done the trick. For the last hour my network has maintained speeds of about 10 MB/s on download, something it hasn’t been able to do for the last few days. I suspect Apple has some work to do on their “self-tuning” Network code.

[Followup Post: Yes,this pretty much fixes my network slowdowns. I just did some Bandwidth tests online, I'm back up to my pre-Leopard speeds.]

There is a great article online at Scientific American’s website investigating the claim that Arthur Eddington and Frank Dyson might have “cooked” the data from their solar eclipse observations in 1919 in a way that supported Einstein’s (then new) General Theory of Relativity:

On May 29, 1919, two British expeditions, positioned on opposite sides of the planet, aimed telescopes at the sun during a total eclipse. Their mission: to test a radical theory of gravity dreamed up by a former patent clerk, who predicted that passing starlight should bend toward the sun. Their results, announced that November, vaulted Albert Einstein into the public consciousness and confirmed one of the most spectacular experimental successes in the history of science.

In recent decades, however, some science historians have argued that astronomer Sir Arthur Eddington, the junior member of the 1919 expedition, believed so strongly in Einstein’s theory of general relativity that he discounted data that clashed with it. [From Fact or Fiction: Did Researchers Cook Data from the First Test of General Relativity?]

The nice thing is this article illustrates one of the less well-appreciated challenges facing the functional scientist: distinguishing between bad data and data that conflicts with your theoretical expectations. Bad data, like other things in life, just happens. And when it happens, it can be a pain to deal with. How do you know when the data is “bad” (that is, the result of a problem at the telescope or a glitch in your software) versus when the data simply conflicts with your theory? In one case, getting rid of the data makes sense. However, being over-eager to reject conflicting data may make you reject a completely compatible alternative interpretation to your observation. Furthermore, if your data seem to support a controversial theory, you should be fairly confident your results are not the result of “bad” data. As Carl Sagan said in Cosmos , “Extraordinary claims require extraordinary evidence.” You have to be pretty confident you haven’t made a mistake if your data strays far from what you expect. Knowing the difference between “bad” data and data that supports a different theory the human part of the science I try to teach my students about. It is also the reason peer-review is such an incredibly important part of the scientific process.

By the way, the verdict of the article’s author is that Eddington and Dyson did the right thing. It turns out it was actually Dyson, who was initially inclined against Einstein’s theory, who made the decision to toss the bad data out. The final results when published^[1] supported Einstein’s General Theory of Relativity, which still stands as the most well-supported model for gravitation to this day.