The extended serial plugin has all the api to fiddle with stty, etc.
On Mar 1, 2008, at 3:48 PM, Robert F. Scheer wrote: > David, > > You're a life-saver! AysncFile methods have no trouble reading and > writing from a properly configured serial port. Just set up the port > properly with stty and it's no sweat. > > It's especially useful to be able to designate /dev/ttyUSBx for a > serial > port that is connected through USB instead of the old RS232 ports. > > I'll do some further tests of timing and blocking but just wanted to > say > THANKS!! > > - Robert -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
On Sat, 2008-03-01 at 14:53 -0800, John M McIntosh wrote: > The extended serial plugin has all the api to fiddle with stty, etc. > This feels a bit out of place being discussed on the developer list but I'm kinda afraid of plugins, having no experience with them yet and having a long way to go with the robot in too short a time. I started reading through the VM material and could see that it would be easy to use only after paying some dues. For example, I couldn't right away figure out where to get the right version of VMMaker for my 3.9.8 VM. To be honest I'm not even certain that's needed for plugins, but that was the impression after skimming some of the material. I'll get back to this and a number of other issues after getting the basic robot loops working and controlling properly. Thanks again for the help. -Robert > On Mar 1, 2008, at 3:48 PM, Robert F. Scheer wrote: > > > David, > > > > You're a life-saver! AysncFile methods have no trouble reading and > > writing from a properly configured serial port. Just set up the port > > properly with stty and it's no sweat. > > > > It's especially useful to be able to designate /dev/ttyUSBx for a > > serial > > port that is connected through USB instead of the old RS232 ports. > > > > I'll do some further tests of timing and blocking but just wanted to > > say > > THANKS!! > > > > - Robert > > -- > = > = > = > ======================================================================== > John M. McIntosh <[hidden email]> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > |
In reply to this post by Andreas.Raab
On 2008 February 28, Andreas Raab wrote:
> Robert F. Scheer wrote: > > Is this behavior well-known and understood or is there something wrong > > with my install? > > This is a very well known issue. Different operating systems have very > different minimal timer resolutions. Generally speaking, on Windows and > Mac OS the timer resolution is very close to 1ms whereas most Linux > kernels have *awful* timer resolutions. I have been told that you can > recompile your kernel to fix it but I'm not sure how. The classic > benchmark to verify your timer accuracy is to do something like here: > > delay := Delay forMilliseconds: 1. > bag := Bag new. > 1000 timesRepeat:[bag add: [delay wait] timeToRun]. > bag sortedCounts > > On my box it yields "a SortedCollection(941->1 51->2 8->3)" which means > that 94.1% of the delays are true 1msec delays. as a comparison, following is squeak 3.9-8 on SuSE 10.3 (2.6.24 kernel): [1151]a SortedCollection(530->44 305->1 34->43 21->2 17->45 11->8 11->41 10->48 10->3 9->42 7->5 6->52 6->4 5->40 2->10 2->11 2->12 2->47 1->7 1->53 1->828 1->17 1->19 1->26 1->31 1->32 1->36 1->955) > > Cheers, > - Andreas |
On Sun, 2008-03-02 at 17:48 +0000, Milan Zimmermann wrote: > On 2008 February 28, Andreas Raab wrote: > > Robert F. Scheer wrote: > > > Is this behavior well-known and understood or is there something wrong > > > with my install? > > > > This is a very well known issue. Different operating systems have very > > different minimal timer resolutions. Generally speaking, on Windows and > > Mac OS the timer resolution is very close to 1ms whereas most Linux > > kernels have *awful* timer resolutions. I have been told that you can > > recompile your kernel to fix it but I'm not sure how. The classic > > benchmark to verify your timer accuracy is to do something like here: > > > > delay := Delay forMilliseconds: 1. > > bag := Bag new. > > 1000 timesRepeat:[bag add: [delay wait] timeToRun]. > > bag sortedCounts > > > > On my box it yields "a SortedCollection(941->1 51->2 8->3)" which means > > that 94.1% of the delays are true 1msec delays. > > as a comparison, following is squeak 3.9-8 on SuSE 10.3 (2.6.24 kernel): > > [1151]a SortedCollection(530->44 305->1 34->43 21->2 17->45 11->8 11->41 > 10->48 10->3 9->42 7->5 6->52 6->4 5->40 2->10 2->11 2->12 2->47 1->7 1->53 > 1->828 1->17 1->19 1->26 1->31 1->32 1->36 1->955) > I found results like this during my testing on Ubuntu (2.6.22 kernel) on one machine that had the "wrong" version of VM installed. You may find that either the VM rpm (deb in my case) from squeak.org or from your SuSe repositories give better results. Also, after installing the linux-rt ("realtime") kernel from Ubuntu repositories, the delay bag performance was horrible, as mentioned earlier, but not in the same league of hurt as the results you've just posted. - Robert > > > > Cheers, > > - Andreas > > > |
On Mon, Mar 3, 2008 at 2:01 PM, Robert F. Scheer <[hidden email]> wrote: Also, after installing the linux-rt ("realtime") kernel from Ubuntu I can't tell if there's just the one real-time Linux which has multiple names or if they're separate projects; I'm seeing linux-rt, Linux/RT, rtlinux, RT-Linux, ... Anyway, if they're all the same thing, then you're not using any of the real-time features: http://www.faqs.org/docs/Linux-HOWTO/RTLinux-HOWTO.html In order to get real-time performance, it sounds like you need to write your real-time code as a kernel module, and the rest of your application (the parts that don't need to be real-time) would run in user-land and communicate using a real-time FIFO character device. Also, by real-time, they really do mean real-time: "Worst case interrupt latency on a 486/33Mhz PC measures well under 30 microseconds, close to the hardware limit." (ref: http://www.linuxdevices.com/articles/AT3694406595.html, assuming it's the same RT-Linux). Gulik. -- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/ |
On Mon, 2008-03-03 at 13:51 +1300, Michael van der Gulik wrote: > > > On Mon, Mar 3, 2008 at 2:01 PM, Robert F. Scheer > <[hidden email]> wrote: > Also, after installing the linux-rt ("realtime") kernel from > Ubuntu > repositories, the delay bag performance was horrible, as > mentioned > earlier, but not in the same league of hurt as the results > you've just > posted. > > > I can't tell if there's just the one real-time Linux which has > multiple names or if they're separate projects; I'm seeing linux-rt, > Linux/RT, rtlinux, RT-Linux, ... > The version in the Ubuntu repository is really a low-latency kernel based on work by Thomas Gleixner and Ingo Molnar. It is basically the standard Ubuntu kernel with their patch tailored for some Ubuntu differences. It is intended to support automation, robotics, telco and multimedia authoring for example. Supposedly, it adds support for high resolution timers and full preemption. (I haven't had time to get into what that really means or requires, sorry). It is not a real "real-time" Linux kernel by any means. It was an easy experiment that I did but not a very serious one. - Robert > Anyway, if they're all the same thing, then you're not using any of > the real-time features: > > http://www.faqs.org/docs/Linux-HOWTO/RTLinux-HOWTO.html > > In order to get real-time performance, it sounds like you need to > write your real-time code as a kernel module, and the rest of your > application (the parts that don't need to be real-time) would run in > user-land and communicate using a real-time FIFO character device. > > Also, by real-time, they really do mean real-time: "Worst case > interrupt latency on a 486/33Mhz PC measures well under 30 > microseconds, close to the hardware limit." (ref: > http://www.linuxdevices.com/articles/AT3694406595.html, assuming it's > the same RT-Linux). > > Gulik. > > -- > http://people.squeakfoundation.org/person/mikevdg > http://gulik.pbwiki.com/ |
On Mon, Mar 3, 2008 at 4:01 PM, Robert F. Scheer <[hidden email]> wrote:
Do the numbers improve if you boost the Squeak process's priority significantly (i.e. "sudo nice -n-10 squeak")? Gulik. -- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/ |
Free forum by Nabble | Edit this page |