Help! My MacBook Pro is suffering from Arrested Development

Acoustic Interloper

So, as some people who helped me out almost a year ago when I bought this machine know, I bought a MacBook pro last year to have a second portable machine for some electro-music applications, as a backup and hopefully a replacement for my lead weight, so called "portable" Alienware XP machine. In fact I bought 3 Macs last year, but my daughter's iMac is with her in New Mexico, and my son's MacBook Pro is in Canada with him at audio school. I'd like to have his at hand to compare with my problems, because he runs ProTools and other audio processing stuff on it, but he's not here.

Anyway, problem number 1 is incoming network traffic often has a terrible case of the slows. I've eliminated the wireless LAN by using wired, and it's not just the web. The XP machines in the house do fine on the web, and moreover -- and this is the important part -- I have a distributed music program I am working on that sends OSC-on-UDP datagrams around, at pretty coarse time granularity. Packets going out of the Macbook to the XP machines arrive at good speed, but the packets coming back to the Mac seem to take forever to get into the Mac and get processed, regardless of whether it is using the wireless or wired LAN. A crappy old Dell laptop that I have performs much better than the MacBook on receiving and using this incoming UDP-LAN traffic. So the consistent symptom here is very slow incoming network traffic, both with LAN-only-musical traffic and web traffic, and it's not tied to either the wireless or wired Ethernet hardware.

I can't find any place in the mac on-line UIs that let me monitor or try to fix the problem. Any suggestions? I've used Ethereal and other traffic analysis tools for years, but I don't see where OSx even gives me a way to look at the problem.

The other problem is that I tested a ChucK application that works fine on the Alienware machine on the MacBook, and on the Mac I get a lot of crackly noise that I don't get on the Alienware. Same Edirol sound box, same sampling rate. I tried playing with the buffers sizes, and also tried the Mac's built-in sound card, on the chance that the Mac Edirol driver is goofy, but still have the crackles. The machines are on par CPU and memory wise, about 3.5 GHz and 2 MB ram, and run the ChucK app in the mix with about a 30% CPU load, which should be fine.

There is something goofy with this machine, so that it winds up almost exclusively being used by my wife and visitors for email and web browsing, which is a big disappointment to me. Any suggestions on how to attack the problem? Thanks.

EDIT: Should have said 2 GB RAM.

BobTheDog · Posted: Fri Jul 18, 2008 10:02 am Post subject:

Hi,

My MacBook Pro uses large amounts of cpu when it has a high network load, up to 80% cpu can be used copying a file to the MacBook over gigabit. I have never worked out why. Apparently they are not meant to.

You can get ethereal using macport http://www.macports.org/ first of all though I would do a simple test of copying a file to the macbook and having a look see if you suffer from the same cpu issue that I do although your issue sounds like it may be a bit different.

I don't know about the edirol device (is it usb?) but the core drivers for the onboard audio are bloody awful, they are real cpu hogs, my RME drivers use 50% of the cpu than the onboard drivers!

Definitely some developers code runs very badly on intel based macs, NI stuff tends to use twice the amount of cpu running on OS X as when running XP on my MacBook pro. I Don' know why, code I have written and benchmarked runs slightly slower under OS X, but not much.

Cheers

Andy

Acoustic Interloper · Posted: Fri Jul 18, 2008 11:33 am Post subject:

BobTheDog · Posted: Fri Jul 18, 2008 11:48 am Post subject:

The UDP stuff sounds very strange, when I first read your last post I thought it may be a Nagel problem but this would only add 200ms per packet, what sort of delay are you seeing?

If it is a Nagel problem this will be caused by your sending code, the socket options should be set up with TCP_NODELAY when using small packets like this. Or you should pad out the data sent a bit to a couple of KB, networking is one of the few fields where sending more data can be quicker, especially under microsoft operating systems.

Blue Hell · Posted: Fri Jul 18, 2008 12:05 pm Post subject:

Nagle

But can it even be used for UDP, don't think so ... anyway, a network sniffer might give some info about where the delays occur. (for windows I use Ethersnoop, not ideal but useful).

elektro80 · Posted: Fri Jul 18, 2008 12:21 pm Post subject:

Have you checked you serial number with Apple Support? At least over here in Norway we have seen some MBPs and MBs with serious networking issues. THis is a hardware issue.

Acoustic Interloper · Posted: Fri Jul 18, 2008 12:53 pm Post subject:

Acoustic Interloper · Posted: Fri Jul 18, 2008 12:55 pm Post subject:

elektro80 · Posted: Fri Jul 18, 2008 12:59 pm Post subject:

Did you do this:
Restart MacBookPro, then press Option-Command-p-r until you hear two start up beeps ?

That´s the NVRAM reset.

Acoustic Interloper · Posted: Fri Jul 18, 2008 1:05 pm Post subject:

Just looked up Nagle. It wouldn't affect the UDP datagrams carrying the game state, since Nagle is TCP, but, if a player makes a move from the Mac, the UDP datagrams showing the board state are preceded by an XML-RPC-over-TCP calls to make the move and if the XML-RPC return value comes back slowly, the display thread in the Mac won't process the UDP datagram until *after* it gets the XML-RPC-TCP response. I'll give TCP_NODELAY a try on *that* connection.

Acoustic Interloper · Posted: Fri Jul 18, 2008 1:06 pm Post subject:

elektro80 · Posted: Fri Jul 18, 2008 1:10 pm Post subject:

Yes, quite safe. Well, unless you have been setting some stuff yourself to the NVRAM and such and you wouldn´t like to have that flushed.. but that I doubt.. Very Happy

The reset is quite OK. You might have to tweak some basic system parameters again.. but those are never of the dangerous or fatal kind.

Trust me. Do it! Very Happy

Acoustic Interloper · Posted: Fri Jul 18, 2008 2:51 pm Post subject:

Did the Option-Command-p-r, didn't hurt anything Very Happy

Still gotta check on that serial number, but

Given the fact that the protocol is:

1. Chess GUI client sends and XML/RPC/TCP call to game server,

2. Game server replies with XML/RPC/TCP result

3. Game server sends individual UDP display updates to all subscribed GUI clients, 1 at a time (I plan to switch to broadcast later)

I set two machines as gui clients of the alienware games server, the mac and a dell, side by side, and took turns making moves from the mac and dell.

When I move from the mac, the dell display updates fast, the mac slow.

When I move from the dell, both the mac and dell update fast.

So, it appears that the mac is not sending out the XML/RPC/TCP call right away. (EDIT: No, that can't be it, otherwise the server wouldn't get the move from the Mac. It's gotta be that the Aleinware responds faster to the Dell than the Mac with the XMLRPC response for some reason!) When the mac does not get involved in making an XML/RPC/TCP call, it is as fast as the dell. The slows have nothing to do with the UDP display update datagrams.

Have not found a way to config a TCP_NODELAY on an XML/RPC client, but I did find this:

BobTheDog · Posted: Sat Jul 19, 2008 1:10 am Post subject:

BobTheDog · Posted: Sat Jul 19, 2008 1:16 am Post subject:

Acoustic Interloper · Posted: Sat Jul 19, 2008 1:55 pm Post subject:

The chess game problem was definitely in the XML-RPC/TCP code, could have been Nagel inside of Python's XML-RPC library (where I can't get at the socket to TCP_NODELAY it), or it could have been problems with Python's XML-RPC library on the Mac. I just rewrote it to get rid of XML-RPC and am using all UDP datagrams instead. Occasionally a UDP datagram gets lost, but clicking the "redisplay" button widget fixes that. Good enough for EM2008.

Apparently my other mac issues are unrelated to this, unless they are TCP generic problems. But that Python XML-RPC library is certainly suspect.

Now, my fast Alienware machine has developed a vertical scar in its display. Had the video card replaced about a year ago. Hope this one isn't dying. Why must these things happen right before I finally get out of the house to play something? Looks like I better hurry up and port the rest of my stuff to the Mac laptop. I may be back with more questions Surprised

I think one reason that people get into the this-OS-camp vs. that-OS-camp is not the OS, but because the apps don't exist or they are hard to port or the libraries work one way on one platform and another way on another. So, once you get used to the pains of your favorite platform, you are loathe to change. I don't have a favorite any more. I'd like a small footprint RTOS with a lot of DSPs on the side, with all the MSP/ChucK/SC libraries available on those DSPs. Of course, I also like to write software that other people can use, so I guess that leaves out special platforms.

I'm going to spend the evening restringing 2 banjos and 2 Appalachian dulcimers. Maybe I can even con my wife into playing one of those.

Thanks for your help!

BobTheDog · Posted: Sat Jul 19, 2008 2:07 pm Post subject:

Acoustic Interloper

Acoustic Interloper · Posted: Wed Jul 23, 2008 1:13 pm Post subject:

Here's a cute portability problem:

Blue Hell · Posted: Wed Jul 23, 2008 2:17 pm Post subject:

http://www.daniweb.com/code/snippet218.html suggests that time.time() might be more compatible.

Acoustic Interloper · Posted: Wed Jul 23, 2008 2:50 pm Post subject:

Blue Hell · Posted: Wed Jul 23, 2008 3:36 pm Post subject:

All my embedded code has the 2038 limit, but hell, I'd be over 80 years old by that time Shocked

Dunno all my devices are built with a life expectancy of 10 years and they don't have to deal with time beyond "tomorrow". Long before the date gets to be a problem the eeproms and flash memories will be worn out and obsolete.

BobTheDog · Posted: Thu Jul 24, 2008 2:10 am Post subject:

You could always use the Hi resolution timers.

Windows - QueryPerformanceCounter()

Unix/linux etc - clock_gettime()

You should be able to get at these somehow, c++ code :