Trouble in Promise-land

What's the first thing you do when you've got a display that has tons of interfaces and bandwidth at its disposal? Try them all at once to see if anything breaks of course. Over the course of the past few days that's exactly what I did. Unfortunately I did find a situation where things broke.

For whatever reason, if you're doing a lot of writes to the Promise Pegasus while playing music (or any other constant audio) through the Thunderbolt Display's internal speakers the audio will eventually corrupt. You can hear exactly what I'm talking about below:

TB Pegasus Audio Issue by AnandTech

This is a recording taken of me listening to music on the Thunderbolt Display (via its internal speakers) while writing a couple hundred gigabytes to the Pegasus R6. Note the introduction of what can only be described as really bad noise at the 6 second marker.

If you stop music playback and quickly resume, the problem will still be there. You have to restart the application that's using the audio codec to recover from this point. From a hardware standpoint, the codec just needs to go through an off/on (sleep/wake?) cycle to return back to normal. If you do this however and haven't stopped the transfer, the problem will creep up again. Stopping the transfer while playing back music won't fix the issue either. You have to stop the transfer and restart the music playback application for it to go away.

The issue goes deeper than that. I went out and bought a Creative Labs X-Fi Go Pro USB sound card to see if the problem stopped at the internal audio codec or extended to all USB sound devices. Unfortunately, it does even happen if you're using an external USB sound card connected to the Thunderbolt Display. Connect the same sound card directly to your Mac or use your Mac's 1/8" stereo jack and the problem goes away.

I was worried that what may appear as noise through speakers could result in data corruption over USB transfers. I ran the Pegasus write test while copying a bunch of files to an SSD attached via USB to the Thunderbolt Display and never saw any corruption on the SSD. This appears to be limited entirely to audio playback.

What's truly bizarre is I can only get the issue to appear when writing to the Pegasus, hundreds of GBs of sequential reads don't seem to produce it. Short bursts of writes don't seem to cause it either. Sending tons of data across the monitor's Gigabit Ethernet, FireWire 800 and USB ports doesn't seem to trigger it either. It appears to be an issue with the Pegasus and the Thunderbolt Display. But which device is ultimately at fault? Is it a problem with the Thunderbolt Display or the Pegasus? Ideally I'd use another Thunderbolt storage device to see if the issue remained, but I couldn't get my hands on a LaCie Little Big Disk.

I thought of something else.

First I needed to test and see if perhaps the issue was related to ultra high speed transfers. As we've already shown, the Pegasus can push as much as 1GB/s over Thunderbolt whereas none of the other bandwidth eaters come even remotely close to that. To determine if the issue was data rate invariant I wrote to the Pegasus at different speeds ranging from 480Mbps all the way up to 7.2Gbps. I tried putting SSDs in the Pegasus as well as standard mechanical hard drives. The problem remained. I got audio corruption regardless of what drives were in the Pegasus or what speed I wrote to the drives. The problem wasn't related to transfer rates.

I also took apart the Thunderbolt Display to confirm there weren't any obvious issues on the controller board (E.g. putting the Thunderbolt IC far too close to the audio controller). Nothing obvious there either.

While I was doing all of this, Apple put forth a Thunderbolt firmware update the other day, however it didn't seem to address the issue either. So I went back to my testing.

Since the problem appeared regardless of how fast (or slow) I was transferring and all I needed was another Thunderbolt storage device to vindicate either the Pegasus or the Thunderbolt Display I turned to the trusty MacBook Air.

As I mentioned in our original Pegasus review, if you have two Thunderbolt equipped Macs and a Thunderbolt cable you can actually put one of the machines in target disk mode and access its drives via Thunderbolt on the remaining Mac. You don't get super high performance but you can get around 500Mbps. Since I had reproduced the audio corruption issue at an even slower data rate I decided to give this a try.

I booted the MacBook Air in target disk mode by holding down the 't' key after turning on the machine. My MacBook Pro was connected to the Apple Thunderbolt Display and a Thunderbolt cable connected the display to the MacBook Air. This was the same setup as the Pegasus, but with the MBA in place of the Pegasus.

I wrote to the MBA just like I did the Pegasus (from a file server connected over the Thunderbolt Display's GigE, transfer rates were capped at around 500Mbps from the file server). After a couple hundred gigabytes were transferred without any audio corruption I swapped out the MBA and connected the Pegasus. I copied the same files at the same rate from the same source. After no more than 7GBs were written to the Pegasus the audio stream started to corrupt.

Based on my testing I can only conclude that the Pegasus seems to be at fault here, not the Thunderbolt Display. Given that the Pegasus was introduced prior to Apple's Thunderbolt Display it's not all that surprising that this issue made it through to production. It's unclear what the root cause is but it's hopefully something Promise can address either through firmware or a driver revision.

Update: I'm still verifying that this is indeed a "fix" but it looks like if you use a USB sound card plugged into a USB hub which is then plugged into the Thunderbolt Display then the sound corruption doesn't happen. This seems to point at noisy power as being the cause with the USB hub acting as a crude filter. It's still not ideal but this may be a workaround for Pegasus users until Promise supplies a fix.

Windows/Boot Camp Experience Dissection
POST A COMMENT

275 Comments

View All Comments

  • Boopop - Friday, September 23, 2011 - link

    OK, so my Dell 2408WFP isn't as big, but in most if not all the tests it outperforms this new monitor. If I was a graphic designer (which I'm not!), even if I had a MBA I reckon I'd stick with a higher quality monitor, and put up with the extra cables.

    On the other hand, if I was the average Joe Bloggs with a MBA, this makes a great monitor for that specific laptop. I like where Apple are going with this, it's just a shame about the lack of many USB ports, and the average screen quality.
    Reply
  • IceDread - Friday, September 23, 2011 - link

    Normally when you test a display you also test the input lag which I find very important. I could not find info about input lag in this review. Reply
  • tipoo - Friday, September 23, 2011 - link

    Not really as important to the target demographic, I think. Most people who get these will be using them for professional tools, so things like colour accuracy are more important than reaction time. If someone is buying one of these and a mac to game on, they've made a pretty bad error, lol. Reply
  • jecs - Friday, September 23, 2011 - link

    You have the general idea right.

    For professionals not demanding the highest color accuracy for print or for broadcast production yes, the Apple monitor is a good choice. That is professionals who work on content creation like internet video, corporate videos or print material among others.

    Serious print houses, photographers or broadcast professionals will choose high end specialized monitors in the range of $3000+, not in the sub $1000.
    Reply
  • JasperJanssen - Saturday, September 24, 2011 - link

    But they will generally only choose that type of monitor for *one* display, where the guy sits who does final colour correction on the output -- not for all the content creation people. (fair enough, if you're large enough that's multiple people, but it's never going to be the majority of your staff). Reply
  • Anand Lal Shimpi - Friday, September 23, 2011 - link

    We normally test input lag by driving a CRT in parallel with the display being evaluated. I didn't have a good way of doing that with a Thunderbolt display unfortunately :-/

    Take care,
    Anand
    Reply
  • JasperJanssen - Saturday, September 24, 2011 - link

    Well, keep it on the list for when the Mac pro comes out, which will hopefully have a videocard with multiple thunderbolt outputs :)

    Come to think of it -- new iMac with dual thunderbolt out and one of them through a VGA dongle? Hmno. Those are active dongles, which mess up results.

    Two PCs, using NTP or something similar to sync up their internal clocks maximally, and one driving a VGA CRT with the other driving the thunderbolt display, each displaying very precisely the current system time in a large font, plus the usual fast shutter speed photography. Your accuracy would depend on the NTP-or-similar protocol. I wonder if you can get close enough with that, over a crossover Gigabit ethernet kept free of other traffic.

    If you do get something like that running, you can also compare input lag between:
    - Display port driving Displayport display
    - Thunderbolt port driving Displayport display
    - Thunderbolt port driving Thunderbolt display
    -Thunderbolt port driving thunderbolt display switched through another TB device or display (add to the chain as possible)

    And even whether displayport mac versus thunderbolt macs are different in this respect when running over the various dongles.

    I would expect a Thunderbolt port running in Displayport mode to be very slightly slower than a real displayport, would be interesting to see if that is the case, and how it compares to a TB port in TB mode, and whether other devices on the chain affect it.
    Reply
  • JasperJanssen - Saturday, September 24, 2011 - link

    "NTP v4 with kernel mods to support it, is capable of much better than 1ms accuracy, possibly as good as 1ns. According to his article, NTP v3 is accurate to 1-2ms in a LAN and 10s of ms in WAN nets. "

    Well, since what you need is ms range, I guess this could actually work.
    Reply
  • sheh - Tuesday, September 27, 2011 - link

    I was curious about that too. Regardless of who the target audience of the monitor is, it's a new technology so I'm curious about its performance vs. DP/DVI/VGA. But could be difficult to tell apart from the panel's logic own latency, at least until there are more TB displays. Reply
  • MrJim - Friday, September 23, 2011 - link

    The Youtube-video in this article, http://www.youtube.com/watch?v=LtAgkIE42jc&fea... , is private. Hard to see then :) Reply

Log in

Don't have an account? Sign up now