On Sunday 04 January 2009, Stephen Wille Padnos wrote: >Gene Heskett wrote: >>[snip] >> >>You are no doubt correct. If the processor can keep up with the math, >> which might imply an fpu in there too, there should be enough pins to >> drive the hdwe. > >Heh - I could be wrong, it's correct to doubt ;) CPU speed hasn't been >the problem for about 10 yearsm even on a PC. It's the interaction with >the real world that's been screwed up so badly lately. > >>>Linux and RTAI support isolated CPUsets. You can tell Linux to not >>>schedule process on certain cores, and then tell RTAI to bind processes >>>to those cores. EMC2 already does this by default when compiled on SMP >>>machines, though you do need to supply the correct boot parameters to >>>the kernel. >> >>Its not been discussed on lkml (in a thread that got my attention), so I >>wasn't aware of how well developed that already was. Thanks. > >You might see something about isolcpus or cpusets if you search lkml. I >think one of the original reasons for adding it was so something like >Oracle could run on its own processors, with its own disks etc. It's >been years since it was added. > >>>In practice, I haven't seen a great improvement from simply going to a >>>multi-core CPU. I haven't tested every machine out there though, so who >>>knows. >> >>Which would imply a bus bandwidth bottleneck maybe? > >I don't think so. I have a machine that I pared down to nothing - no X, >ext2, most services like sound disabled (it's a bare HAL application, so >I don't need the GUIs and all). This runs with a core2 duo chip (dual >core around 2 GHz). Latencies were in the 16000 range before my >runscript optimizations, they went down to about 5000-6000 after (unless >I connect with ssh and actually use network or remote X software - then >they shoot back up to 15-16k). When I use an isolated CPU, I get >roughly the same numbers, I don't recall exactly. Strangely, if I put a >do-nothing load on the Linux core (literally the bash line 'while true ; >do echo "nothing" > /dev/null ; done'), latencies drop to around 200 or >less, with some spikes to the 1000 range. Yes, I mean under 1 >microsecond, and usually under 200 nanoseconds. Note that this is with >an Intel CPU which shares cache and memory controllers between processor >cores. I haven't tried the same setup on an AMD multicore CPU, I may do >that some time just for the heck of it.
I'd be interested in what data falls out of that. >>I don't have a very good >>mental estimate of how many actual gates are between the cpu and a pin of >> the parport. > >Many, but it's not gate delays that cause issues. > >>With the parport having fallen from favor, I can easily see that >>path getting slower and slower while others become more optimized to speed >> up the popular stuff. That is just how things are. > >It's only when you get to many-axis systems with loads of encoders and >other I/O that the parport becomes "too slow". Remember, it's about >interrupt latency first (which is independent of the interface you use), >data turnaround second, and throughput a distant last. > >>Someone, maybe you, once made the comment that an accessory card for the >>parport was actually faster than the onboard. Have any tests been made to >>somewhat define what the possible speedups might be? 10% isn't much, 400% >>would solve real problems I'd think. > >Jon Elson has a lot of eperience with this, as well as Peter Wallace. I >don't think it was me :) >A plain old I/O card with 8255s or similar, connected via PCI bus, >should be faster than a parport. Parallel ports have extra delay logic >to make sure they don't exceed the parallel port specs, which may be the >main reason why they all take around a microsecond (+/- a few hundred >ns) per I/O operation, regardless of bus or CPU speed. It was the FCC mandated filtering that was put into printers for noise suppression reasons about 25 years ago that resulted in that. When every pin on the printers centronics connector had a .05uf and a big ferrite bead, the parports had to slow down. I had to build a latching circuit and put it between a coco3 and one of those printers else it printed only about half the chars sent, and garbled them beyond recognition. The stock ls245 parport chip folks put on a coco to even get a parport, was only active during the write cycle, so the data nor the strobe ever had a chance to get to a settled value before the chip was again tristated. >>I have a Rosewill dual port card I am going to put into my shop box to >> drive the lathe with when and if I get the lathe controllable, and I have >> the 3 axis xylotex card I took from the mill when I made the rotary table >> drive for it & put a 4 axis xylotex on it. That Rosewill card is an 8255 lookalike. >Take a look at the Mesa 7i43 card. It's an FPGA card that connects to >the parallel port and provides 48 I/Os which can be configured as PWM, >step generator, encoder input, etc. It's like $89 in single quantity. Next summer maybe, I've been copying the mail about it here. :) >- Steve Thanks, Steve. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) When you dig another out of trouble, you've got a place to bury your own. ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
