interface woes and apogee duet questions

it is the same bus...your logic is quite correct.....and it seems, apple rectified the situation by losing the fw400 port, effectively clearing up any confusion and allowing people to get the speeds they should be from their equipment

 

i don't know if i could get any clearer a result than the 'superduper' clone experiment that i tried

 

This makes sense, too. But keep in mind that cloning a drive is not the same as recording (writing) 2 mono tracks at the same time. Or playing back (reading) a bunch of already recorded tracks.

 

J.

of course, you are correct, very different....

but i would be inclined to believe that it would be 50% of whatever task

like you, i blissfully ran all my projects like this for 4 years with no issues...or did i ?? i wonder if some of the, few, overloads i did get were due to this....

I found some interesting info about firewire that I didn't know:

Isochronous and Asynchronous transfers:

FireWire supports two types of data transfer: Asynchronous and isochronous. Asynchronous transfer provides acknowledged, guaranteed delivery of data and is targeted to a specific node with an explicit address. If the data you’re sending is not error-tolerant, such as data written to a disk drive, asynchronous transfer is appropriate.

 

Isochronous transfer, on the other hand, is broadcast in a one-to-many or one-to-one manner. Before a node begins to send or receive isochronous data, it requests a particular amount of bandwidth and one or more isochronous channels. A channel can have one transmitter of data (or talker) and any number of receivers (or listeners). Isochronous transfers do not allow for error-checking or retransmission but they do deliver data at a constant, real-time rate. If you’re sending time-critical, error-tolerant data, such as a video stream, isochronous transfers are preferable.

Quoted from this article:

http://developer.apple.com/library/mac/#documentation/DeviceDrivers/Conceptual/WorkingWFireWireDI/FWDevOverview/FWDevOverview.html

So even if an audio interface shares the same firewire bus with a hard drive, they don't use the same type of data transfer.

This thread is also interersting, and mentions the Isochronous vs Asynchronous bit (the last post is most interesting to our discussion):

http://arstechnica.com/phpbb/viewtopic.php?f=19&t=94941

And from the Focusrite (eek!) Answerbase:

Isochronous vs. Asynchronous Firewire Data Transfer

The data traffic between FireWire devices and nodes is divided into isochronous and asynchronous transfers. Isochronous transfers provide guaranteed transmission opportunities at defined intervals. However, if a packet is not received successfully, it is not resent. In asynchronous transfers, the intervals between transmissions can vary, but data can be resent if it's missed. FireWire is one of very few interfaces that support both isochronous and asynchronous data transfer. It can reserve up to 80% of its bandwidth for one or more isochronous channels to support applications that require real-time data transmission.

 

Because the firewire bus is permitted to allocate up to 80% for isochronous data transfer, at least 20% is always available for asynchronous transfer. This is used for all normal computer type data transfers, because it guarantees data delivery. For example, firewire hard disks use asynchronous data transfer.

Source: http://www.focusrite.com/answerbase/en/article.php?id=186

J.

More reading material:

http://homepages.nyu.edu/~rah232/FireWire.pdf

J.

el-bo, did some benchmarks for you to check out.

I used the numbers game demo project (how appropriate!) and played it back from a noisy Lacie d2 Quadra drive, using FW800. 40 tracks in that project (though they don't have stuff in them going on at the same time all the time), with a buffer size of 256:

-Without the Duet (using built-in audio)

• Results 57.22
  System Info
  Xbench Version 1.3
  System Version 10.5.8 (9L30)
  Physical RAM 4096 MB
  Model MacBookPro3,1
  Drive Type LaCie d2 quadra
   
  Disk Test 57.22
  Sequential 77.80
  Uncached Write 98.87 60.71 MB/sec [4K blocks]
  Uncached Write 84.33 47.71 MB/sec [256K blocks]
  Uncached Read 46.65 13.65 MB/sec [4K blocks]
  Uncached Read 124.91 62.78 MB/sec [256K blocks]
  Random 45.25
  Uncached Write 16.42 1.74 MB/sec [4K blocks]
  Uncached Write 132.25 42.34 MB/sec [256K blocks]
  Uncached Read 80.18 0.57 MB/sec [4K blocks]
  Uncached Read 133.76 24.82 MB/sec [256K blocks]

-Duet on the FW400 Port

• 
  Results 56.08
  System Info
  Xbench Version 1.3
  System Version 10.5.8 (9L30)
  Physical RAM 4096 MB
  Model MacBookPro3,1
  Drive Type LaCie d2 quadra
   
  Disk Test 56.08
  Sequential 78.47
  Uncached Write 91.43 56.14 MB/sec [4K blocks]
  Uncached Write 83.46 47.22 MB/sec [256K blocks]
  Uncached Read 49.74 14.56 MB/sec [4K blocks]
  Uncached Read 125.79 63.22 MB/sec [256K blocks]
  Random 43.63
  Uncached Write 15.50 1.64 MB/sec [4K blocks]
  Uncached Write 137.63 44.06 MB/sec [256K blocks]
  Uncached Read 79.85 0.57 MB/sec [4K blocks]
  Uncached Read 135.26 25.10 MB/sec [256K blocks]

-Duet Daisy-chained to the Lacie (MBP > Lacie > Duet)

• Results 56.10
  System Info
  Xbench Version 1.3
  System Version 10.5.8 (9L30)
  Physical RAM 4096 MB
  Model MacBookPro3,1
  Drive Type LaCie d2 quadra
   
  Disk Test 56.10
  Sequential 79.13
  Uncached Write 92.84 57.01 MB/sec [4K blocks]
  Uncached Write 81.31 46.00 MB/sec [256K blocks]
  Uncached Read 51.57 15.09 MB/sec [4K blocks]
  Uncached Read 123.66 62.15 MB/sec [256K blocks]
  Random 43.45
  Uncached Write 15.47 1.64 MB/sec [4K blocks]
  Uncached Write 134.98 43.21 MB/sec [256K blocks]
  Uncached Read 80.31 0.57 MB/sec [4K blocks]
  Uncached Read 132.39 24.57 MB/sec [256K blocks]

J.

el-bo, did some benchmarks for you to check out.

 

I used the numbers game demo project (how appropriate!) and played it back from a noisy Lacie d2 Quadra drive, using FW800. 40 tracks in that project (though they don't have stuff in them going on at the same time all the time), with a buffer size of 256:

 

-Without the Duet (using built-in audio)

 

• Results 57.22
  System Info
  Xbench Version 1.3
  System Version 10.5.8 (9L30)
  Physical RAM 4096 MB
  Model MacBookPro3,1
  Drive Type LaCie d2 quadra
   
  Disk Test 57.22
  Sequential 77.80
  Uncached Write 98.87 60.71 MB/sec [4K blocks]
  Uncached Write 84.33 47.71 MB/sec [256K blocks]
  Uncached Read 46.65 13.65 MB/sec [4K blocks]
  Uncached Read 124.91 62.78 MB/sec [256K blocks]
  Random 45.25
  Uncached Write 16.42 1.74 MB/sec [4K blocks]
  Uncached Write 132.25 42.34 MB/sec [256K blocks]
  Uncached Read 80.18 0.57 MB/sec [4K blocks]
  Uncached Read 133.76 24.82 MB/sec [256K blocks]

 

-Duet on the FW400 Port

• 
  Results 56.08
  System Info
  Xbench Version 1.3
  System Version 10.5.8 (9L30)
  Physical RAM 4096 MB
  Model MacBookPro3,1
  Drive Type LaCie d2 quadra
   
  Disk Test 56.08
  Sequential 78.47
  Uncached Write 91.43 56.14 MB/sec [4K blocks]
  Uncached Write 83.46 47.22 MB/sec [256K blocks]
  Uncached Read 49.74 14.56 MB/sec [4K blocks]
  Uncached Read 125.79 63.22 MB/sec [256K blocks]
  Random 43.63
  Uncached Write 15.50 1.64 MB/sec [4K blocks]
  Uncached Write 137.63 44.06 MB/sec [256K blocks]
  Uncached Read 79.85 0.57 MB/sec [4K blocks]
  Uncached Read 135.26 25.10 MB/sec [256K blocks]

 

-Duet Daisy-chained to the Lacie (MBP > Lacie > Duet)

 

• Results 56.10
  System Info
  Xbench Version 1.3
  System Version 10.5.8 (9L30)
  Physical RAM 4096 MB
  Model MacBookPro3,1
  Drive Type LaCie d2 quadra
   
  Disk Test 56.10
  Sequential 79.13
  Uncached Write 92.84 57.01 MB/sec [4K blocks]
  Uncached Write 81.31 46.00 MB/sec [256K blocks]
  Uncached Read 51.57 15.09 MB/sec [4K blocks]
  Uncached Read 123.66 62.15 MB/sec [256K blocks]
  Random 43.45
  Uncached Write 15.47 1.64 MB/sec [4K blocks]
  Uncached Write 134.98 43.21 MB/sec [256K blocks]
  Uncached Read 80.31 0.57 MB/sec [4K blocks]
  Uncached Read 132.39 24.57 MB/sec [256K blocks]

 

J.

the only thing i can make out (i don't speak 'tech' ) is that they all seem pretty similar, which i'm guessing is your point

is it, the fact that these two types of data streams don't hinder each other ?? but if you were to put a fw400 drive into the port, instead of the interface, it would halve the speed ??

have i misunderstood eveything ??

and, if so, it still wouldn't explain the superduper readings i got (which i'm now starting to think i dreamt) as the set up was with an interface plugged in that wasn't even used, the 50% speed decrease being a result of it just being plugged in

please excuse my ramblings, it is 2:30am, here

both he and i were using the two separate ports on the older macbook pros....unlike the hub of your diagram, this DOES have the effect of halving the fw800 speed

I just re-read through this thread and found this interesting because if you have two firewire ports on your machine that are on one bus then inside the machine you basically have a FW hub. Why would the theory/example of how an external hub transmits date be any different than an internal hub?

el-bo, read that pdf thesis I linked, and again look for Isochronous and Asynchronous transfers.

Audio interfaces use Isochronous while HD's use Asynchronous. Here's a quote from that thesis:

isochronous packets have priority on the bus over other types of packets such that devices sending them are guaranteed bandwidth. In other words, if an audio device is using, say, 4Mb/s of bus bandwidth and a disk drive starts doing things on the bus too, that audio device will continue to operate without glitches because its isochronous packets have priority over the asynchronous packets of the disk.

I think this is what's happening with superduper. Superduper's bandwidth is being limited by the audio interface's isochronous transfer priority. What I don't know for sure if this priority exists even if there no audio being played back (wouldn't make sense)...were you playing back audio while cloning with superduper? I'm also use superduper so I'll test this later.

Once thing's for sure though, the amount of data read and written by superduper is HUGE, compared to whatever audio project you may have.

J.

J.

Why would the theory/example of how an external hub transmits date be any different than an internal hub?

the simple answer ??....i don't know

I'm defragging one of my firewire drives to be able to create a partition to do a superduper clone and do more tests with the duet.

J.

el-bo, read that pdf thesis I linked, and again look for Isochronous and Asynchronous transfers.

 

Audio interfaces use Isochronous while HD's use Asynchronous. Here's a quote from that thesis:

 

isochronous packets have priority on the bus over other types of packets such that devices sending them are guaranteed bandwidth. In other words, if an audio device is using, say, 4Mb/s of bus bandwidth and a disk drive starts doing things on the bus too, that audio device will continue to operate without glitches because its isochronous packets have priority over the asynchronous packets of the disk.

 

I think this is what's happening with superduper. Superduper's bandwidth is being limited by the audio interface's isochronous transfer priority. What I don't know for sure if this priority exists even if there no audio being played back (wouldn't make sense)...were you playing back audio while cloning with superduper? I'm also use superduper so I'll test this later.

Once thing's for sure though, the amount of data read and written by superduper is HUGE, compared to whatever audio project you may have.

 

J.

 

J.

when cloning, i never do anything else....i don't want to risk something being written badly because i'm diverting the hard drive, off course

i can't try the superduper thing again, due to my drive not working properly (one of the points of this thread), but i'm pretty definite that this is how it happened

i still don't understand how your first quote correlates with the figures you posted above....

Once thing's for sure though, the amount of data read and written by superduper is HUGE, compared to whatever audio project you may have.

again, while true, is just a 'relative' position...we may only need a 5400rpm/fw400 drive for most of our projects...but it is this 'apparent' speed loss which is in question

if you get time to try the 'superduper' experiment, it would be good...you don't have to complete the pass, but you do need to leave it going for a good few minutes, as it seems to take a while to spin up to it's maximum transfer rate

:)

Again, make sure you understand what asynchronous and isochronous transfer methods are about.

Here's another quote (this one's from wikipedia).

The process of the bus deciding which node gets to transmit data at what time is known as arbitration[4]. Each arbitration round lasts about 125 micro-seconds[4]. During the round, the root node (device nearest the processor) sends a cycle start packet[4]. All nodes requiring data transfer respond, with the closest node winning[4]. After the node is finished, the remaining nodes take turns in order. This repeats until all the devices have used their portion of the 125 micro-seconds, with isochronous transfers having priority[4]. Up to 80% of the time can be given to isochronous nodes[4].

What I think happened (though I still need to do the tests) in your superduper situation was that, *possibly* the mere presence of the isochronous device (audio interface) slowed down the asynchronous device (HD serving as clone destination) just because the audio interface had priority over the actual cloning as far as firewire is concerned.

J.

Again, make sure you understand what asynchronous and isochronous transfer methods are about.

 

Here's another quote (this one's from wikipedia).

 

The process of the bus deciding which node gets to transmit data at what time is known as arbitration[4]. Each arbitration round lasts about 125 micro-seconds[4]. During the round, the root node (device nearest the processor) sends a cycle start packet[4]. All nodes requiring data transfer respond, with the closest node winning[4]. After the node is finished, the remaining nodes take turns in order. This repeats until all the devices have used their portion of the 125 micro-seconds, with isochronous transfers having priority[4]. Up to 80% of the time can be given to isochronous nodes[4].

 

What I think happened (though I still need to do the tests) in your superduper situation was that, *possibly* the mere presence of the isochronous device (audio interface) slowed down the asynchronous device (HD serving as clone destination) just because the audio interface had priority over the actual cloning as far as firewire is concerned.

 

J.

but, unless i'm missing something, the priority given to isochronus transfer would exist in the studio situation because the priority would be given to the interface, resulting in less coming from the drive.....if the audio interface is not actually sending any packets, as in the cloning, why is this showing the most drastic effect ?? if it slows it, just by it's being connected, then surely this applies to the studio situation (even before any recording has started)

i'm not being argumentative for the sake of it, i'm sure i just don't understand...

but, unless i'm missing something, the priority given to isochronus transfer would exist in the studio situation because the priority would be given to the interface, resulting in less coming from the drive.....if the audio interface is not actually sending any packets, as in the cloning, why is this showing the most drastic effect ?? if it slows it, just by it's being connected, then surely this applies to the studio situation (even before any recording has started)

 

i'm not being argumentative for the sake of it, i'm sure i just don't understand...

i think the question here should be "how much bandwidth would I need for a "studio situation"?

I wasn't even able to perform the benchmark when duping my internal to the F800 external with superduper. The benchmark program returned a error -35 (several times), which appears to be a "No Such Volume" or "volume not found" error:

http://farm6.static.flickr.com/5206/5204178812_3f8d504d97.jpg

I'm going to have to try it by booting from another clone, and see if it's possible that way (after all, the benchmark program lives in the internal disk where the data is being copied from).

I now suspect that superduper uses all the bandwidth it can get when cloning, and the fact that an audio interface is present (Up to 80% of the time can be given to isochronous nodes) just bogs it down.

We could ask thsuperduper's developer, but at this point I'm convinced that whatever you do, audio won't eat as much bandwidth.

J.

Well, I'm happy to say that after various tests, I'm convinced that having a FW400 audio interface like the Duet connected at the same time as a FW800 device (HD), (each in their own port) won't cripple the entire firewire bus (essentially making the FW800 device behave like FW400 one)...at least until someone proves otherwise.

el-bo, I monitored SuperDuper!'s behavior with and without having the Duet connected to the FW400 port:

With Duet:

http://farm6.static.flickr.com/5290/5206559904_c78b4c24a9_z.jpg

Without Duet:

http://farm5.static.flickr.com/4126/5206559850_8a9687f1c0_z.jpg

Note that the "Effective copy speed" is practically the same in both scenarios.

Also, I only see a Elapsed Time counter in SuperDuper!...where did you see that SuperDuper!'s time to completion was doubled when having your FW400 device plugged in?

Here's what Activity Monitor showed (here I'm monitoring Disk Activity for the external FW800 drive):

With Duet:

http://farm5.static.flickr.com/4092/5206560024_d6db803ef1_b.jpg

Without Duet:

http://farm6.static.flickr.com/5209/5205962535_f597debc37_b.jpg

Finally something I did not expect:

SuperDuper! worked faster when Logic was playing back the numbers game (from the internal), when one would think that having the Duet processing audio would slow down SuperDuper!'s cloning:

http://farm5.static.flickr.com/4089/5205962467_6718415b2b_z.jpg

J.

that's bizarre...it's a while since i tried it and, because of my drive issues, i can't try it myself....

i was sure there was an eta...maybe not...maybe i was calculating, using the 'elapsed'...there was something about it, that made me draw this conclusion...i wonder, if it had been left longer whether the speed of the transfer might have ramped up

i'm glad you are doing these tests....i'm not doubting you, and am encouraged by the results...it bodes well

of course, there is one more 'ultimate test'

that's bizarre...it's a while since i tried it and, because of my drive issues, i can't try it myself....

 

i was sure there was an eta...maybe not...maybe i was calculating, using the 'elapsed'...there was something about it, that made me draw this conclusion...i wonder, if it had been left longer whether the speed of the transfer might have ramped up

 

i'm glad you are doing these tests....i'm not doubting you, and am encouraged by the results...it bodes well

 

of course, there is one more 'ultimate test'

I'm also just interested in finding the truth about all this...

Before I did the first test I linked from the other LPH thread, I was under the impression (I had heard) that a firewire 800 bus gets slowed down by the mere pressence of a FW400 device (eachin their own port). Now I'm pretty sure it is not like that.

The only problems I've had with this setup have always been RAM or CPU-related, but I know how to work around those quite well when I need to.

Occasional system overload/disk too slow errors? Of course! But not enough to piss me off (and I get pissed off easily, believe me!) I've seen people with Mac Pros/3gbit SATA drives posting in this forums that they get them as well.

J.

that's bizarre...it's a while since i tried it and, because of my drive issues, i can't try it myself....

 

i was sure there was an eta...maybe not...maybe i was calculating, using the 'elapsed'...there was something about it, that made me draw this conclusion...i wonder, if it had been left longer whether the speed of the transfer might have ramped up

 

i'm glad you are doing these tests....i'm not doubting you, and am encouraged by the results...it bodes well

 

of course, there is one more 'ultimate test'

 

I'm also just interested in finding the truth about all this...

Before I did the first test I linked from the other LPH thread, I was under the impression (I had heard) that a firewire 800 bus gets slowed down by the mere pressence of a FW400 device (eachin their own port). Now I'm pretty sure it is not like that.

The only problems I've had with this setup have always been RAM or CPU-related, but I know how to work around those quite well when I need to.

Occasional system overload/disk too slow errors? Of course! But not enough to piss me off (and I get pissed off easily, believe me!) I've seen people with Mac Pros/3gbit SATA drives posting in this forums that they get them as well.

 

J.

i have slightly more processor sped than you, but slightly less ram...it would seem that neither of us has suffered, particularly, using this setup

but, i am still crious

perhaps, one last test...and there really is no rush

duplicate an audio passage to a project, running from the external drive.....keep stacking the audio tracks till the project is on its knees...i wonder which, if any, of the configurations will allow for more stackage

duplicate an audio passage to a project

I'm not sure what you mean by that...?

i wonder which, if any, of the configurations will allow for more stackage

Which configurations are you particularly interested in (for testing)?

Who will do the optibay test for example? By the way, you do know our machines' SATA only goes up to 1.5Gbit/s, right? I say so because I also have a expresscard to esata adapter and the difference in speed between it and firewire 800 wasn't much better. Maybe optibay is better, but I won't believe until they prove it to me!

J.

By the way, you do know our machines' SATA only goes up to 1.5Gbit/s, right?

i do now this is turning out to be quite the education...even at 1.5gb/s it is faster, though....right ???

the optibay, for me, also has a lot to do with portability....the smallest external drives i have seen that are up to the task are from american websites, which, when delivered to spain lose a lot of their pice advantage...the optibay doesn't work out so much more expensive....where do you shop for stuff like this ?? any european places that compare to 'owc'

what i meant about audio files and configurations ??....copying the audio file onto as many separate tracks as you can, before the project seizes up.....first with just the external drive, connected...then with the apogee in the 400 port, at the same time to see how it compares...then with the apogee daisychained to the fw800 drive

if the difference in track count is miniscule then it shows we really have nothing to worry ourselves with

hey snr. jordito

i don't mean to sound too demanding...you have already done so much to further the cause

it seems i might be able to help with the last test, after all

2 bits of good news

have decided to go with the duet...my fears concerning the breakout cable have disappeared, since it turns out that replacements are only $25..not that that is the cheapest, or that i don't intend to take care of it, but i would have expected them to cost 3-4 times as much to replace

the other bit of good news is that i've salvaged my fw800 drive....for a while now, i've only been able to mount it, using the fw400 connection...tried resetting PRAM, to no avail....then i read about resetting the SMC / PMU.....tried it and it worked a treat...i can now mount the drive with fw800

sorted...

when the interface arrives (hopefully before christmas), i'll try the tests with the audio tracks to see what, if any effect, the different configurations have

cheers

I was under the impression (I had heard) that a firewire 800 bus gets slowed down by the mere pressence of a FW400 device (eachin their own port). Now I'm pretty sure it is not like that.

I guess this confirms that an internal hub acts pretty much like an external hub (after all, why wouldn't it?). Allowing devices to transmit data at their nominal speed. Exactly what I had suspected.

both he and i were using the two separate ports on the older macbook pros....unlike the hub of your diagram, this DOES have the effect of halving the fw800 speed

 

Why would the theory/example of how an external hub transmits data be any different than an internal hub?

Thanks for all the effort Jordito!

Thanks for all the effort Jordito!

No problem! I still need to run the test el-bo proposed....probably next week.

@el-bo: Where do I buy my computer stuff here in Spain? Unless it's a USB drive, a flash drive, or similar (for which I go to the usual places: Media Markt, FNAC, even PC City); yes OWC. There are some Spanish online stores too which carry way more stuff than those other stores. I can't give you names right now, but I bought RAM for my MBP from one of those.

Good to hear you've made up your mind about the duet. Good choice!

J.

Thanks for all the effort Jordito!

 

No problem! I still need to run the test el-bo proposed....probably next week.

 

@el-bo: Where do I buy my computer stuff here in Spain? Unless it's a USB drive, a flash drive, or similar (for which I go to the usual places: Media Markt, FNAC, even PC City); yes OWC. There are some Spanish online stores too which carry way more stuff than those other stores. I can't give you names right now, but I bought RAM for my MBP from one of those.

 

Good to hear you've made up your mind about the duet. Good choice!

 

J.

great stuff...found a good price on a 2tb iomega drive in the u.k...i think the postage would work out better from there...but that is gonna be further down the line...there's no more money

i'm really excited about getting the apogee, actually...even just for itunes...it's quite a popular unit on hifi forums, also...people use it as a headphone amp...hopefully, it will give my grado's something to sing about

i'll get on with some trials of my own, when it arrives

OK, Mr. el-bo here's the results of that test that was pending.

Disk I/O meter with 140 stereo tracks at 48kHz (duplicated audio files). The project and its files reside in a external FW800 drive...

1-Built-In audio (Duet not connected):

http://farm6.static.flickr.com/5086/5247366872_13b5cb644f_b.jpg

2-Duet as Core Audio device (FW400 port):

http://farm6.static.flickr.com/5281/5247366762_b7f7d8595e_b.jpg

Very slight difference. I didn't get the Disk Too Slow error, so I could have added more tracks (not many, though). Being a still image you don't see that the meter is actually jumping up every 2 seconds or so...

J.

Oh, almost forgot...here's with the Duet side-chained to the HD:

http://farm6.static.flickr.com/5249/5246906255_6dd8bb3063_b.jpg

J.

you absolute star

so, really there is not much difference

thank you, very much

still haven't forgotten about this

once i have finished my latest project, i can test a couple of things out

i've recently bought a second internal hard drive for my macbook pro and a caddy to put in place of the optical drive...of course, now the offending external drive seems to be a lot more stable

in march, i'll fit the new drive and then check the difference between the different configs, firewire ports and how they compare to an internal sata (1.5)

hasta la pasta

hey, jordito

would it be possible to share the settings involved in the test you showed above, and even the audio file if possible

i am having problems getting even half that amount of tracks with my external firewire and would like to eliminate all the differences

cheers