The days of one G5 being enough are dead! Here comes the

[qo]

Originally posted by MichaelCanavan:
First of all hi qo! What the hell is TDC doing anyway?

Now, that's a great question! I have no idea Michael. I've talked with a couple of the OSXA mods and they're silent on what's going on. I just noticed that the static page has been updated again. So, that's a good sign, I guess? Looks like TDC is implying, with the new update, that he's strapped for time.

[Michael Canavan]

Originally posted by qo:

Originally posted by MichaelCanavan:
First of all hi qo! What the hell is TDC doing anyway?

Now, that's a great question! I have no idea Michael.

[filtertone]

Originally posted by dixiechicken:


However enormously powerful future G5-systems does
not seem very likely for a long time to come,
since Apple is starting it's switch to Intel
processors.


(unless we're talking about certain gaming consoles
wich Apple doesnt produce anyway)

Intel will eventually produce quad-cpu:s I'm certain -
that may find their way into Apple computers.
That is still some years away though.

Cheers: Dixiechicken

This is what I culled from various Apple rumor (the key word here) sites: The high-end Intel Macs are to be last out of the gate, sometime in 2007, preceded by all manner of lower-end machines. Apple will not let the current Dual 2.7s to be the last PowerMac upgrade for the next 1.5 years. Maybe the next rev will be dual duals, maybe not. Apple is still going to produce new G5-based Macs in the interim.

<small>[ July 27, 2005, 10:52 PM: Message edited by: filtertone ]</small>

[grimepoch]

I agree as well that we'll still see probably a few more G5 versions, and I believe IBM just announced a dual core PowerPC within the last two weeks.

I mean, it's not that IBM doesn't have the technology already going as well, with their hand in the Cell processor in the PS2 and the multicore processor in the Xbox360, they are probably pulling a lot of that technology together from things like the Power4 chip which I believe has five cores in it? Or maybe that was eight (It's what the G5 is based off of).

Regardless if it is Intel or IBM, I think you are going to see quad and higher core processors much sooner. I mean, you have people buying dual processor AMD machines for their home systems, I cannot believe how many people I've seen using them.

I believe OSX is already setup to use past two processors since it is based on BSD, but I couldn't say for sure.

Ideally, I'd like to see the Cell processor approach reached for the processor, however, benchmarks from programmers on the new game systems are a bit less than stellar. Sure, the processors are fast as hell, however, speed means nothing without an understanding of the pipeline. It could just take more clock cycles to do the same thing. Another issue might be that there is a migration of technology issue. If you are used to writing single processor optimized apps, going to a multiprocessor model is more difficult.

What I REALLY think we need is a TDM based network between computers. Ethernet does not provide that, you have no guarantee of time on the network, and as it gets busier, the collisions become greater. This is okay for data transfer with no latency requirement. But, imagine the technology of the Token Ring in a studio. Then, you'd know how much you could push through the cable because it would be dedicated.

I have run many tests of using audio and MIDI over ethernet 100Mbit. MIDI is fine, I don't believe you see much more latency than when you are running all 8 outs of your MIDI ExpressXT. However, introduce 2 stereo channels at 48k-16bit, and I get drop-outs and stuck notes like you'd not believe. Optimized? No, because I still have my internet connection hanging off the router, but I use the internet constantly. 100Mbit should be more than sufficient for 2 48k-16bit channels.

Do they even still sell token ring anymore?

[Timeline]

Optimized? No, because I still have my internet connection hanging off the router, but I use the internet constantly. 100Mbit should be more than sufficient for 2 48k-16bit channels.

Forget that until fiber direct connect. At that point the entire ball game changes.

[qo]

Originally posted by enc0der:
What I REALLY think we need is a TDM based network between computers. Ethernet does not provide that, you have no guarantee of time on the network, and as it gets busier, the collisions become greater. This is okay for data transfer with no latency requirement. But, imagine the technology of the Token Ring in a studio. Then, you'd know how much you could push through the cable because it would be dedicated.

I have run many tests of using audio and MIDI over ethernet 100Mbit. MIDI is fine, I don't believe you see much more latency than when you are running all 8 outs of your MIDI ExpressXT. However, introduce 2 stereo channels at 48k-16bit, and I get drop-outs and stuck notes like you'd not believe. Optimized? No, because I still have my internet connection hanging off the router, but I use the internet constantly. 100Mbit should be more than sufficient for 2 48k-16bit channels.

Do they even still sell token ring anymore?

I'm sure that Ethernet, in and of itself is not the problem. Rather, it's the implementation of the host adaptor and IP stack and, perhaps, the design of low-end ethernet switches. There are no collisions in modern Ethernet networks. The host-switch links are full-duplex. Switches, depending on design, can switch frames internally at rates far higher than externally and can also be designed to be non-blocking. It's simply a matter of cost.

Token Ring offers no benefit over switched ethernet. The one benefit it used to offer was larger frame sizes (4096 vs 1500 bytes). But, we now even support 9180 byte frames in ethernet. This is moot though since large frames are not conducive to low latencies.

IMHO, what needs to happen is someone needs to develop a commercially viable hardware implementation of IP. This has already been done in various labs for years, and there have been a couple commercial products for servers (HP, I believe, developed something like this several years ago). The internal path for ethernet/IP in a host is something like:

ethernet frame-->host adaptor-->buffer-->system packet memory-->IP stack-->application

There are several context switches that happen along the way, that could be eliminated in a dedicated ethernet/IP host adaptor. The path would then look something like:

ethernet frame->new adaptor->application memory

What would be required here is a rework of the Unix inetd daemon (basically stick it in flash-upgradable firmware). The adaptor would then do all the parsing to determine the TCP/UDP port (application) to hand the payload off to. It would then simple place the contents directly in application memory for the app to process. IMHO, it's this path that is the bottleneck. Not ethernet. IP over Token Ring would suffer the same fate with current architectures.

One other area that could be leveraged for audio is IP's TOS bits. These would give an indication to the IP stack to expedite e.g. audio over other IP packets. But, I really don't think this would help much since most of us, when we work with audio, don't have other apps running that are sending/receiving IP. So, there's no contention in the IP stack between non-realtime and realtime packets anyway.

Bottom line, IMHO, we need hardware assisted IP. I know that Intel is working on integrating this into their processors (there's a pretty big body of research out there on taking common system components and rolling them into a single core). Hopefully, we'll see the fruits of this research/labor creep out of Intel and into Macs in a few years.

[grimepoch]

Interesting, it's been a few years since I worked with the fine details of the network stack, I do use a router and not a hub, so I must be getting better performance in that regard.

In my case, I had two seperate machines sending audio to the main G5 machine. In this case, there are two computers talking to one computer. What happens in this case? Each machine cannot be talking at once, so how does it handle the switching between the two of them? Does it block until it can allow the switch to be made to the second machine? Is there a lot of overhead in that transistion? Does it put them all on the same line in that case for which you would have collisions between both machines trying to send to the G5?

In this situation, I'd like to guarantee that each machine got a specific amount of time to talk to the G5.

Thought, that said, maybe I am just having bus problems. Is trying to send all this data through ethernet not getting the bandwidth it needs because I am using the firewire port for 20 channels of 44.1k/16bit and the USB port for 8 channels of MIDI? In other words, when does the PCI bus start having problems. I know that on my G3 long ago, my PCI bus was my bottleneck, I could run enough devices at once that I'd start getting drop-outs, and it was because things like the SCSI card were totally hogging the PCI bus (and the video card).

When I get a bit of free time, I think I am going to experiment more with the audio over ethernet to try and determine what is causing me to get such poor performance, it should really not have a problem with 2 stereo channels the more I think about it. Maybe if I just rethink this a bit.

[qo]

Hi Rick,

From the perspective of the router/hub two machines sending to one machine can be problematic if the traffic is at rates that exceed (or approach) the line rate of the egress port (connecting the destination machine).

With ethernet switches, when packets from two ingress interfaces contend for the same egress interface, we buffer the packet from one of the ingress interfaces. The details of the buffering can make a difference in certain situations. For instance, if you buffer on the ingress interface(s), perhaps as a result of internal egress to ingress flow control throttling them, you can experience something called Head of Line Blocking (HOL) where all ingress interfaces are held up due to congestion on a single egress interface. HOL is a pretty well understood phenomenon though, but I can imagine it might be present in low-end switch/routers.

From the receiving host's perspective, there's no "hit" in switching between handling traffic from two hosts. However, you are correct in that there is currently no way to prioritize traffic from one host over traffic from other hosts. IP allows such prioritization (Type of Service, aka TOS bits in the IP header) and even ethernet has COS bits (Class of Service), but actually taking advantage of these, in a practical sense, isn't straightforward. The tools are there though, under the hood. It's just that Apple doesn't provide a nice interface to access them.

Just for grins, I'm going to take my low-end NetGear hub to work and test it. I work for one of the large network equipment companies and regularly use e.g. Ixia traffic generator/analysor in my work. I'd never thought to borrow this gear to test the equipment I have at home. It'd be interesting to see how it compares to the stuff we develop (I work on a particularly high-end switch/router that's used in service provider and enterprise backbones, and in data centers).

Anyway, my guess is that the NetGear's interfaces all share the same packet buffer memory. It'll be interesting to see the latency through this box as well as loss percentages at various traffic rates and packet sizes.

One experiment you might want to do (though it can only involve two macs) is to connect them back to back with a crossover ethernet cable and see if you get better performance. Note, that a router does more than a switch and is (generally) slower than a switch (assuming it's a software-based router, which most low-end products are). The reason is that it has to strip the ethernet header, look into the IP header, decrement the TTL by one, determine the IP destination address, figure out the outgoing interface for that address (and the media type for that interface), build a media header that matches the media type (e.g. ethernet, DSL) and that has the correct L2 (e.g. ethernet) destination address (e.g. that of your mac, which it determines through ARP), prepend that to the IP header, and then send the packet. A switch has to do much less since it's not modifying the packet at all since, generally, a switch's interfaces are all the same media type.

So, if you ARE using a router between your macs, you may want to reconsider. On the other hand, your router may be a combination switch/router. Typical home products include two router interfaces (one internal, and one WAN interface that connects to your service provider, which can be either ethernet, or something like DSL). The internal interface connects to an internal port on the ethernet switch and the other external ports on these products are all ethernet switch ports. You can tell if this is the case by going to each Mac, opening Terminal and issuing:

ifconfig

Note the IP address of each mac, and it's netmask, and either post them here, or google "subnet calculator" and determine if they are on the same subnet.

An easier way actually, is to open Terminal and issue:

traceroute <address of other mac>

If only one line is printed, then they are on the same network.

If two lines are printed, and the first line contains an IP address of your router, then the macs are on separate networks. In this case, I'd recommend you buy a switch, connects your macs to this new switch, and connect the switch to the router.

I'm late for work so haven't proof-read the above. Apologies!

EDIT: just proof read, corrected typos, added some stuff.

<small>[ July 28, 2005, 02:10 PM: Message edited by: qo ]</small>

[TedRackley]

Hi all,

I work for Muse, and one of the guys at Alto Music told me you were discussing Receptor in here, so I read this LONG thread and decided to clarify a few things:

1) If you own the license to use a plugin, like for example, Spectrasonics Stylus RMX, you can use it as an RTAS, VST or an AU. We could have chosen AU or RTAS Mac as the format Receptor runs, but 99.9% of the "for sale" commercial plugins out there get released as a VST for Windows. Plus, there are thousands of freeware and shareware plugins in that format, and wouldn't you like to be able to use them all? If you own an AU plugin, you also own the license for the VST version , and you certainly have the license to run it on any machine you want, including the Receptor.

2) If you hate Windows, no worries, Receptor runs a custom Receptor OS based on a Linux kernel, but is not a Linux OS. If you plugin in a monitor (or attach an ethernet cable to your Mac and run the Receptor Remote Control Utility, which comes on CD-ROM) to see the Receptor GUI (you don't have to, you can control all parameters from the front panel knobs and buttons), there is no desktop, nor folders, no floating windows, Dock/Taskbar, or trash can. There are 3 pages: Mix, Setup and Edit. The Receptor cannot run DP or Pro Tools, nor any applications, no email/internet/word processing stuff, it strictly hosts plugins. As a result, the Receptor can give you more polyphony and lower latency for Virtual Instruments than any Mac or PC you could buy. How do I know this?.....

3) Benchmark: Just for reference, I chose one of the more CPU-intensive plugins out there, a virtual analog, physically modelled VI with built-in effects, a new one called the miniMonsta from G-media/GForce which is now distributed by M-Audio. Putting the mini into polyphonic mode and holding down my sustain pedal, I can get 24 voices of polyphony without distortion or crackles (24 minimoogs!)when running it on Receptor at a buffer size of 256 samples (which is the highest setting on Receptor, the lowest is 32 samples, which will yield less polyphony). For you film/TV/video game composers, using NI Kompakt with a large string section patch, I got 256 stereo voices of polyphony on the Receptor.

On my Dual G5 2 Ghz/2GB RAM, RME HDSP at 256 sample buffer running V-Stack and the same minimonsta patch, I got 12 voices of polyphony before crackling/distortion.

On my WinXP/tweaked for audio/Dual 2.2 Ghz Opteron, 2GB RAM, 500GB SATA RAID, RME HDSP/Nuendo 8 I/O system running V-Stack at 256 sample buffer size, I got 22 voices of polyphony before crackling/distortion.

Now when you consider the street price of the Receptor is around $1399, and the cost of my massive Dual-Opteron is in the $6000-7000 range, and the Receptor still outperformed it, it's pretty impressive, which is why I wanted to work for the company. For $6k, you could buy 3 Receptors. Now how much polyphony do you have?

4) In a few weeks we will release our UniWire technology, which sends multiple ports of MIDI and multiple channels of audio over ethernet into your host app, in your case DP, via VST/AU/RTAS plugins you just insert on your mixer. No MIDI interface or soundcard drivers to install, just a new DSP-Accelerator, but unlike TDM, UAD-1, Waves and Powercore, we don't make the plugins, the 3rd parties do, so our platform is not proprietary. Can your Powercore or UAD run fxpansions BFD? Or the VSL running on NI Kontakt 2?

My point is that even if you have a TDM or other DSP accelerator system, most of the plugins that run on them are FX, not instruments, and usually only certain effects. What about your other 3rd party effects and instrument plugins? One VI that uses lots of CPU power, loads lots of samples into RAM and also does disk streaming, like say Kontakt 2, will still bring your G5 to its knees...s the title of this topic is suggesting. The Receptor is a solution that works now.

Any questions? Let me know. Should we start another topic since this one is SO long?

ted@museresearch.com

Thanks guys!

[chrispick]

Originally posted by TedRackley:
In a few weeks we will release our UniWire technology, which sends multiple ports of MIDI and multiple channels of audio over ethernet into your host app, in your case DP, via VST/AU/RTAS plugins you just insert on your mixer. No MIDI interface or soundcard drivers to install, just a new DSP-Accelerator, but unlike TDM, UAD-1, Waves and Powercore, we don't make the plugins, the 3rd parties do, so our platform is not proprietary. Can your Powercore or UAD run fxpansions BFD? Or the VSL running on NI Kontakt 2?

Now, that's what I was talking about. Looking forward to hearing more.

[toodamnhip]

Receptor sure looks interesting.

I'm glad I started this topic as bitching and moaning is not the goal. It was to try to find a solution. Who here thinks receptor is a step in the right direction? I think it might be. I'd like to know more about any bugs it has.

Dave

[qo]

Low end vs high end switches.

Above, I referred to low-end and high-end switches, and figure that folks, who's area of expertise is music production and not networking, may not grok this. We all understand specs that differentiate low-end from high-end audio gear, but what about network stuff? What separates a $30 ethernet switch from a $300,000 ethernet switch/router? I'll try to give an overview below.

1. Queuing

Low end switches typically have a single input queue and single output queue per interface. All packets go into the same queue. Therefore these products can't differentiate between packets i.e. prioritize one packet over another. This is the main point that Rick was making. That the network doesn't have the capability to make this prioritization. And, he's right; given current low-end products.

A high-end switch will have multiple queues per port; from low-priority to high-priority. The number of queues depends on the implementation and the cost. Once you integrate multiple queues, you have also to develop a way to manage packet flow into and out of these queues (i.e. a servicing regime). Ethernet frames can be placed into different queues depending on the COS value (Class of Service, as defined in IEEE 802.1p) in the ethernet header. High-end switch/routers can even map IP TOS (Type of Service) to ethernet COS, or vice versa and allow users to configure the mapping (there are more COS values than TOS values, so you typically create an internal table that maps ranges of COS to TOS values).

Now, this is all well and good, but how do these values get set in the first place? Either the host that's sending the traffic can set them (there are tools in e.g. BSD, Linux, Windoze) and so I'm sure there are also tools in OSX, but probably Terminal-based, to set these values. High-end switches can also be configured to remap these values as they receive frames from certain ports, or from certain IP source addresses.

(as an aside, we usually refer to ethernet frames and IP packets) but these terms are used loosely)

2. Hardware-based forwarding

High-end switch/routers do all their packet header processing in hardware using specialized ASICS. Typically, a hardware IP router uses software to setup the hardware based on it's routing table (which is generated either manually, or dynamically by speaking with adjacent routers using protocols like e.g. OSPF, EIGRP, RIP in local networks, or BGP in wide area networks). The hardware is preconfigured with the media type and next hop associated with each IP destination address range, so the ethernet header is, in essence, pre-built. All this requires additional, and fast, mechanisms to store/access. Typically, TCAMS are used to store this info.

Low-end switch/routers use software exclusively to forward packets. It's easy to build a router using a PC, Linux, and freely available software like e.g. Zebra. The router is as "fast" as the PC's processor, and will be able to forward with no drops to the extent that the PC ethernet interface cards can buffer incoming packets that the PC's processor is taking time to handle.

As mentioned above, high-end switch/routers use specialized hardware to forward packets at line rate, and even to reclassify them (i.e. edit their COS/TOS fields) at line rate. The only time buffering of incoming packets is required is when there is contention on the output. And, even here, depending on the switch, the internal speed of the switch can sometimes be 3x or more of the speed of a single interface. Too, packet "flows" through a high-end switch are distributed. That is, you can have multiple, simultaneous, flows occuring in a switch at a given time, with no buffering at all, due to distributed, and autonomous, packet processing hardware. We're talking aggregate packet forwarding rates of millions of packets per second for high-end switch/routers, vs hundreds of packets per second for low-end.

3. Management

Not typically interesting unless you have large/complex networks, but on-board management facilities (e.g. SNMP/RMON, syslog, CLI based statistics, "call home" functionality, etc) all add to the cost of a switch/router.

So, why do I mention all this? Back when it was all just web and email, and the network was not even considered for audio/video use, none of this mattered. But, as Rick points out, it's now starting to matter. Not only within the network (even our home/studio networks), but also within the host.

My guess is that a decent hardware-based IP network interface card could be developed for $250 or so retail. Ethernet cards are now from $9 to $20. They used to be $1500 when they were first introduced back in the mid-80's. I think an "IP card" that includes host-based (hopefully standardized) management that allowed you to set the COS/TOS of packets that you are sending based on application, or destination address, or some other variable, is a given. It's just a matter of time. It's also just a matter of time before high-end features in switchs and routers start to trickle down into products that we all can afford. At that point, it becomes a matter of developing a new skill set to be able to leverage the new capabilities to our advantage. Some things never change

[qo]

Hi Ted,

I looked through the Receptor product info HERE, but have a question. If we're running sample-based VST's, how much RAM and disk does the Receptor come with, and is this upgradable? Is there an e.g. FW port on it to add additional disk? I confess to not having read the manual (which is nice that you guys have made available online).

All in all, it looks like a great product!

[Timeline]

Vey cool Allen!

Brother Jim said Fiber is the future. What up wit dat?

[qo]

Originally posted by Timeline:
Vey cool Allen!

Thanks!

Brother Jim said Fiber is the future. What up wit dat?

Yep, I agree with your brother that fiber is the future. Fiber is even the present! And, the same protocols that run over copper also run over fiber. From an equipment standpoint, it's just a different PHY (networking lingo for physical layer). The standards bodies divide the networking space up into different layers. The ISO (International Standard Organization) defined a 7-layer model for networking called OSI (Open Systems Interconnect). This is pretty much dead, in that the IETF and IP trounced OSI's butt in the late 80's and early 90's and came up with a practical set of protocols that you could actually code and build called TCP/IP. But TCP/IP is also layered, as follows:

Layer 5-7 (applications)
Layer 4 (transport i.e. UDP/TCP)
Layer 3 (routing i.e. IP)
Layer 2 (inter-device link protocols, e.g. ethernet, DSL, Token Ring, Fibre Channel, FDDI, etc)
Layer 1 (physical media e.g. fiber, copper, wireless)

Any layer can (theoretically) run on top of any other layer, for example:

Digital Performer over UDP over IP over Fibre Channel over fiber.

Or

Logic over TCP over IP over ethernet over copper.

Sort of plug and play, interchangeable, hardware/software modules, if you will. So, whether fiber or copper is underneath, is a choice that we can make based on our needs. Fiber's strengths are long distance, bandwidth capacity, security (can't tap it easily), and (especially for us audio guys) ground isolation.

Really, the market decides what wins within a given layer (e.g. Token Ring lost, ethernet won). Then it starts to commoditize the winner (ethernet became MUCH cheaper after Token Ring lost).

<small>[ July 28, 2005, 11:54 AM: Message edited by: qo ]</small>