Re: [Emc-users] unexpected realtime delay
On Tue, 15 Mar 2011 21:06:59 -0400, you wrote: I had this problem on my mill that has a D510 board in it. I have not had the error pop up since disabling hyper threading in bios and adding isolcpus to the boot file. FWIW... Which boot file? Steve Blackmore -- -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
From the EMC Wiki: Edit */boot/grub/menu.lst* and add *isolcpus* parameter to the end of the kernel line of the RTAI kernel. The value of the *isolcpus* parameter will be the number of the last core/CPU. Start to count from #0. 1 for dual core/CPU system, 3 for quad core/CPU etc... This is the kernel line for my dual core machine /kernel /vmlinuz-2.6.30.5-rtai root=/dev/sda5 ro *isolcpus=1*/ Les On 02/04/2011 12:08, Steve Blackmore wrote: On Tue, 15 Mar 2011 21:06:59 -0400, you wrote: I had this problem on my mill that has a D510 board in it. I have not had the error pop up since disabling hyper threading in bios and adding isolcpus to the boot file. FWIW... Which boot file? Steve Blackmore -- -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
On Sat, 02 Apr 2011 12:48:10 +0100, you wrote: From the EMC Wiki: Edit */boot/grub/menu.lst* and add *isolcpus* parameter to the end of the kernel line of the RTAI kernel. The value of the *isolcpus* parameter will be the number of the last core/CPU. Start to count from #0. 1 for dual core/CPU system, 3 for quad core/CPU etc... This is the kernel line for my dual core machine /kernel /vmlinuz-2.6.30.5-rtai root=/dev/sda5 ro *isolcpus=1*/ Hi Les - there is no menu.lst file in my grub directory. I thought I'd read that grub changed with 10.04? Steve Blackmore -- -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
the newer grub is quite different from the older On my 10.04 I had to edit the /etc/default/grubfile to look like this #ORIGINAL LINE WAS GRUB_CMDLINE_LINUX_DEFAULT=quiet splash to GRUB_CMDLINE_LINUX_DEFAULT=quiet splash isolcpus=1 and then run sudo update-grub the kernel now boots with the isolcpus=1 hope this helps... On Sat, Apr 2, 2011 at 7:23 AM, Steve Blackmore st...@pilotltd.net wrote: On Sat, 02 Apr 2011 12:48:10 +0100, you wrote: From the EMC Wiki: Edit */boot/grub/menu.lst* and add *isolcpus* parameter to the end of the kernel line of the RTAI kernel. The value of the *isolcpus* parameter will be the number of the last core/CPU. Start to count from #0. 1 for dual core/CPU system, 3 for quad core/CPU etc... This is the kernel line for my dual core machine /kernel /vmlinuz-2.6.30.5-rtai root=/dev/sda5 ro *isolcpus=1*/ Hi Les - there is no menu.lst file in my grub directory. I thought I'd read that grub changed with 10.04? Steve Blackmore -- -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Fred Kehler ( fred.keh...@gmail.com) -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Joel Jacobs wrote: Ok, found something interesting. I left the isolcpus=1 in grub and re-enabled hyper-threading and latency topped out around 11.2us with acceptable performance. I thought it should be fixed so ran EMC2 and after a few hours the error tripped again. Here is the details from dmesg: It looks to me that the 1058805 is the problem child here and it's not an Unexpected realtime delay at all. Looks like an Unexpected premature execution of the thread! Any idea what could cause this Right, but the code that monitors execution time doesn't have specific limit values, it just looks at recent history and looks for ANY variance. If the process is normally not being retained in CPU cache, but on occasion it IS retained in cache, then it will execute faster that time. Otherwise, due to some configs doing more work on particular thread executions (such as when the trajectory planner is running at a sub-multiple of the servo thread) you can get these variances. Anyway, I don't think a 111 us fluctuation should be a problem for a 700 us thread. A tool that monitors cushion, ie how much non-real time is left over when the real time thread runs might be useful. As long as even a LITTLE time is left over on ever thread, then there is no problem. If even once in a blue moon there is zero time left, or an overrun, then it IS a problem. Jon -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Joel Jacobs wrote: Ok, found something interesting. I left the isolcpus=1 in grub and re-enabled hyper-threading and latency topped out around 11.2us with acceptable performance. I thought it should be fixed so ran EMC2 and after a few hours the error tripped again. Here is the details from dmesg: [snip] At first glance it looks like the 1058805 is the outlier here, not the 1273653 it's complaining about. Anyway I'm trying to make sense of these numbers. Earlier in the dmesg output is this: [ 62.467909] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 1800221000 hz. So, f=1800221000, p=1/f, servo thread = p*n (n=numbers from dmesg) clocksservo threadjitter 1259487 = 699.629us -0.371us -0.0535% 1262655 = 701.389us +1.389us +1.984% 1058805 = 588.153us -111.847us -15.978% 1265220 = 702.814us +2.814us +0.402% 1248228 = 693.375us -6.625us -0.946% 1273653 = 707.498us +7.498us +1.071% 1273653 / 1058805 = 1.20291555. This is slightly more than the 20% threshold. It may be true that the detection method should be changed, since it's asymmetric (downward deviations are more significant than upward, since the calculation is more or less max/min). In practice though, it's not a deviation of 20% from normal, it's a range which is more than 20% of the lowest measurement in the buffer. It looks to me that the 1058805 is the problem child here and it's not an Unexpected realtime delay at all. Looks like an Unexpected premature execution of the thread! Any idea what could cause this? Sure, maybe the message could be changed to Unexpectedly high jitter in realtime thread, but I don't know if that makes any more sense to anyone. - Steve -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Stephen Wille Padnos wrote: Sure, maybe the message could be changed to Unexpectedly high jitter in realtime thread, but I don't know if that makes any more sense to anyone. What REALLY matters, is that the system is not running dangerously close to running out of headroom, where the real time thread uses up the entire period of that thread. Percentage fluctuation of a thread's run time is in itself not a problem, overrunning the alloted time for the thread to execute is THE actual problem to be avoided. It seems the data needed to figure out the time remaining IS available. Maybe a new test to see if the time remaining is less than 20% of the thread's period would be a better test. If you are only running a single thread, this will work. If you have two (or more) real time threads, however, the test becomes more complicated. But, at the end of the cycle of the slowest thread, you could review the execution times of all the threads over the slow thread's period to see if any of them have run down t wire, so to speak. Jon -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Hi Peter, I think you meant to say 20% not 120% since you gave the example of 200ms jitter will trip the error with a 1ms servo thread. I had a chance to do some further testing. I ran the latency test for longer - a couple hours and the servo thread jitter just barely exceeded 14us which is exactly 2% of my servo thread (700us) so I'm thinking the error is tripping at only 2% jitter - remember I have no base thread. I tried turning off hyper-threading and adding the isolcpus=1 to grub and the latency numbers about halved and no more delay errors - BUT - It has severely affected the computers performance so I won't leave it that way. I would rather just clear the error. I think 2% jitter on the servo thread is perfectly acceptable. My motors are running smooth as silk and performing well. So if it's supposed to trip at 20% and mine seems to trip at 2% have I discovered a bug or is this a problem exclusive to my system? Maybe someone else running a servo only system could try setting their servo period to 40x max jitter and see if the error is generated. That would make the error 2.5% - enough to trip if it is in fact tripping at 2%. Anyway, no biggie. I don't mind clearing the error since it only pops up once per run. It would be different if it was nagging me. Joel Jacobs On Tue, Mar 15, 2011 at 3:29 PM, Peter C. Wallace p...@mesanet.com wrote: On Tue, 15 Mar 2011, Joel Jacobs wrote: Hi, Is there any way to adjust the sensitivity or suppress this error? I have an Atom D525 running the latest EMC2 You will still get unexpected realtime delay errors with just a servo thread if the latency gets to be more than 120% of the servo period (this would be 200 uSec at a 1ms servo thread period) This is a fairly serious amount of latency and probably should be looked into. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Joel Jacobs wrote: Hi Peter, I think you meant to say 20% not 120% since you gave the example of 200ms jitter will trip the error with a 1ms servo thread. I had a chance to do some further testing. I ran the latency test for longer - a couple hours and the servo thread jitter just barely exceeded 14us which is exactly 2% of my servo thread (700us) so I'm thinking the error is tripping at only 2% jitter - remember I have no base thread. Yes, for some time I have thought the error message threshold is set a bit too sensitively. A 10% variation of run time for a real time component is certainly cause for worry, but one should leave enough overhead for the occasional burst of DMA or other activity that slows the CPU down. When these error messages occur, more information on the exact amount of run time variance is put in the /var/log/messages file, easiest to examine recent ones with the dmesg command. With only a 700 us servo thread, your CPU should not be real heavily loaded, so even a 10 or 20% increase in run time is not likely to overrun the next scheduled execution of the thread. Fortunately, these messages are only notices, and don't affect the machining. I tried turning off hyper-threading and adding the isolcpus=1 to grub and the latency numbers about halved and no more delay errors - BUT - It has severely affected the computers performance so I won't leave it that way. I would rather just clear the error. I think 2% jitter on the servo thread is perfectly acceptable. Check the dmesg report, and if it really is just a 2% overrun, go ahead and ignore it. My motors are running smooth as silk and performing well. So if it's supposed to trip at 20% and mine seems to trip at 2% have I discovered a bug or is this a problem exclusive to my system? Maybe someone else running a servo only system could try setting their servo period to 40x max jitter and see if the error is generated. That would make the error 2.5% - enough to trip if it is in fact tripping at 2% What really is important is the normal run time for the entire thread vs. the scheduling interval. If there is more than 20% headroom there, I wouldn't worry about it. Jon -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Ok, found something interesting. I left the isolcpus=1 in grub and re-enabled hyper-threading and latency topped out around 11.2us with acceptable performance. I thought it should be fixed so ran EMC2 and after a few hours the error tripped again. Here is the details from dmesg: [16870.928322] 24014168: ERROR: Unexpected realtime delay: check dmesg for details. [16870.928333] [16870.928336] In recent history there were [16870.928338] 1259487, 1262655, 1058805, 1265220, and 1248228 [16870.928341] elapsed clocks between calls to the motion controller. [16870.928350] This time, there were 1273653 which is so anomalously [16870.928354] large that it probably signifies a problem with your [16870.928357] realtime configuration. For the rest of this run of [16870.928360] EMC, this message will be suppressed. At first glance it looks like the 1058805 is the outlier here, not the 1273653 it's complaining about. Anyway I'm trying to make sense of these numbers. Earlier in the dmesg output is this: [ 62.467909] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 1800221000 hz. So, f=1800221000, p=1/f, servo thread = p*n (n=numbers from dmesg) clocksservo threadjitter 1259487 = 699.629us -0.371us -0.0535% 1262655 = 701.389us +1.389us +1.984% 1058805 = 588.153us -111.847us -15.978% 1265220 = 702.814us +2.814us +0.402% 1248228 = 693.375us -6.625us -0.946% 1273653 = 707.498us +7.498us +1.071% It looks to me that the 1058805 is the problem child here and it's not an Unexpected realtime delay at all. Looks like an Unexpected premature execution of the thread! Any idea what could cause this? Joel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
great list! I have had this error popping up all the time since I upgraded to the 10.04 distribution ( seldom on the 8.04, same computer) and the isolcpu=1 seems to have solved it... does it follow then that the second cpu in this case is not being managed by the realtime kernel? I am currently running my emc on the second core 'taskset 2 emc ***.ini', and it seems impervious to the dreaded error message, regardless as to what else I run on the machine... but am I safe in running this way? am I still getting realtime performance on the core that has been isolated on bootup? thank you to all the contributors! On Tue, Mar 15, 2011 at 6:06 PM, Tom Easterday tom-...@bgp.nu wrote: I had this problem on my mill that has a D510 board in it. I have not had the error pop up since disabling hyper threading in bios and adding isolcpus to the boot file. FWIW... -Tom On Mar 15, 2011, at 3:22 PM, Joel Jacobs wrote: Hi, Is there any way to adjust the sensitivity or suppress this error? I have an Atom D525 running the latest EMC2 from the repositories (Ubuntu 10.04). I have a Mesa 7I43 and Gecko 320 servo drives. I have no base thread at all, just the servo thread running at 700us. At 1ms I would get random 'thunks' from the servo only while jogging the X axis in the + direction at 120ipm. Minus X Jogs were smooth. After adjusting the servo thread to 700us all motors are super smooth no matter what. Just randomly getting this error - sometimes takes an hour to pop up. Like I said, the motors are running great so I don't really want to tweak the hyperthreading and isocpu= stuff. I don't understand why I'm getting this error with no base thread. Thanks, Joel Jacobs -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Fred Kehler ( fred.keh...@gmail.com) -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
On 03/23/2011 12:52 PM, Fred Kehler wrote: great list! I have had this error popping up all the time since I upgraded to the 10.04 distribution ( seldom on the 8.04, same computer) and the isolcpu=1 seems to have solved it... does it follow then that the second cpu in this case is not being managed by the realtime kernel? No, the second cpu is *only* running the realtime kernel (I think unless an application explictly uses it), and everything else is put on the first cpu. I am currently running my emc on the second core 'taskset 2 emc ***.ini', and it seems impervious to the dreaded error message, regardless as to what else I run on the machine... but am I safe in running this way? am I still getting realtime performance on the core that has been isolated on bootup? thank you to all the contributors! You should be getting better realtime performance on that core now, since nothing else should be using it. The realtime stuff only uses one core anyhow (someone correct me if I'm wrong), but with isolcpu it gets the core to itself. Moses -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
You can start with: 1) disabling the hyperthreading and 2) dedicating one of Atom's cores to EMC (and other RTAI functions) by adding isolcpus=1 to grub Unfortunately I cannot explain in more detail, how exactly to do it, so I can only advice asking uncle google. Viesturs 2011/3/15 Joel Jacobs j...@sdf.lonestar.org: Hi, Is there any way to adjust the sensitivity or suppress this error? I have an Atom D525 running the latest EMC2 from the repositories (Ubuntu 10.04). I have a Mesa 7I43 and Gecko 320 servo drives. I have no base thread at all, just the servo thread running at 700us. At 1ms I would get random 'thunks' from the servo only while jogging the X axis in the + direction at 120ipm. Minus X Jogs were smooth. After adjusting the servo thread to 700us all motors are super smooth no matter what. Just randomly getting this error - sometimes takes an hour to pop up. Like I said, the motors are running great so I don't really want to tweak the hyperthreading and isocpu= stuff. I don't understand why I'm getting this error with no base thread. Thanks, Joel Jacobs -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
On Tue, 15 Mar 2011, Joel Jacobs wrote: Date: Tue, 15 Mar 2011 15:22:04 -0400 From: Joel Jacobs j...@sdf.lonestar.org Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: emc-users@lists.sourceforge.net Subject: [Emc-users] unexpected realtime delay Hi, Is there any way to adjust the sensitivity or suppress this error? I have an Atom D525 running the latest EMC2 from the repositories (Ubuntu 10.04). I have a Mesa 7I43 and Gecko 320 servo drives. I have no base thread at all, just the servo thread running at 700us. At 1ms I would get random 'thunks' from the servo only while jogging the X axis in the + direction at 120ipm. Minus X Jogs were smooth. After adjusting the servo thread to 700us all motors are super smooth no matter what. Just randomly getting this error - sometimes takes an hour to pop up. Like I said, the motors are running great so I don't really want to tweak the hyperthreading and isocpu= stuff. I don't understand why I'm getting this error with no base thread. Thanks, Joel Jacobs You will still get unexpected realtime delay errors with just a servo thread if the latency gets to be more than 120% of the servo period (this would be 200 uSec at a 1ms servo thread period) This is a fairly serious amount of latency and probably should be looked into. I suspect your random thunks are also latency related. Possible fixes: Disable SMI Disable screensaver Make sure all power management is off in BIOS Disable monitor mode-set setting a reasonable value of stepgen maxaccel in the HAL/INI file will make the hardware stepgen more tolerant of latency -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Thanks for the suggestions! Running the latency test program seemed to top out around 15us which I was quite pleased with but never ran the test more than 10 min or so. I have bios power management and screen saver disabled. Just read about the SMI thing in the wiki and I would like to do some testing I guess but it said it could damage the CPU so I gotta ask, has there been any reports from the EMC community of damaged motherboards caused by disabling this? How about success stories? I came up empty searching for monitor mode-set what is that? Thanks much, Joel Jacobs -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Unexpected realtime delay
On Sun, 2007-04-29 at 21:05 +0800, 杜少华 wrote: Every time I start the emc2,it reports that unexpected time delay. I has this problem as well fixed it by replacing the video card. The system was a 400MHz P2 on an Intel Seattle2 motherboard with an AGP bus S3 VGA card. I replaced the S3 card with a PNY brand Nvidia MX200 card the problem disappeared. I realized what the problem was when I switched from a CRT monitor to a LCD. I observed green streaky artifacts on the display every time I moved the mouse. I came to suspect that the card was tying up the bus for unusually long periods if mouse interrupts were causing problems with screen redraws. I might just bring this card to fest... Matt - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Unexpected realtime delay
杜少华 wrote: I made a module named Mlink under HAL,It uses the IRQ 10 and cycle time is 1 ms. Every time I start the emc2,it reports that unexpected time delay. I don't know why it happened?And does it influnce the realtime thread of emc2? HAL uses periodic threads, not interrupts. I have no idea how you are using IRQ10 in a HAL based system, but it is probably confusing the time measurements that are used to calculate the unexpected real delay error. Regards, John Kasunich - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Gentlemen, I have started getting this message also. I start EMC and as soon as I move an axis I get this message. I haven't tried to troubleshoot this but if someone would like me to try or look at something on my machine, I will. thanks Stuart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
On Sun, Apr 29, 2007 at 11:26:29AM -0500, Stuart Stevenson wrote: Gentlemen, I have started getting this message also. I start EMC and as soon as I move an axis I get this message. I haven't tried to troubleshoot this but if someone would like me to try or look at something on my machine, I will. thanks Stuart http://wiki.linuxcnc.org/emcinfo.pl?TroubleShooting - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Unexpected realtime delay
Looks like -n didn't get what you may need so I also did -v [EMAIL PROTECTED]:~$ lspci -n :00:00.0 0600: 8086:2530 (rev 04) :00:01.0 0604: 8086:2532 (rev 04) :00:1e.0 0604: 8086:244e (rev 04) :00:1f.0 0601: 8086:2440 (rev 04) :00:1f.1 0101: 8086:244b (rev 04) :00:1f.2 0c03: 8086:2442 (rev 04) :00:1f.3 0c05: 8086:2443 (rev 04) :00:1f.4 0c03: 8086:2444 (rev 04) :00:1f.5 0401: 8086:2445 (rev 04) :01:00.0 0300: 10de:002d (rev 15) :02:0a.0 0780: 9710:9815 (rev 01) :02:0b.0 0c03: 1033:0035 (rev 43) :02:0b.1 0c03: 1033:0035 (rev 43) :02:0b.2 0c03: 1033:00e0 (rev 04) :02:0d.0 0780: 14f1:1036 (rev 08) [EMAIL PROTECTED]:~$ lspci -v :00:00.0 Host bridge: Intel Corporation 82850 850 (Tehama) Chipset Host Bridge (MCH) (rev 04) Flags: bus master, fast devsel, latency 0 Memory at f800 (32-bit, prefetchable) [size=64M] Capabilities: available only to root :00:01.0 PCI bridge: Intel Corporation 82850 850 (Tehama) Chipset AGP Bridge (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 32 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 Memory behind bridge: fc90-fe9f Prefetchable memory behind bridge: f060-f46f :00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 I/O behind bridge: d000-dfff Memory behind bridge: fea0-feaf Prefetchable memory behind bridge: f470-f47f :00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 04) Flags: bus master, medium devsel, latency 0 :00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 04) (prog-if 80 [Master]) Subsystem: Intel Corporation: Unknown device 4d44 Flags: bus master, medium devsel, latency 0 I/O ports at ffa0 [size=16] :00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #1) (rev 04) (prog-if 00 [UHCI]) Subsystem: Intel Corporation: Unknown device 4d44 Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at ef40 [size=32] :00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 04) Subsystem: Intel Corporation: Unknown device 4d44 Flags: medium devsel, IRQ 9 I/O ports at efa0 [size=16] :00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #2) (rev 04) (prog-if 00 [UHCI]) Subsystem: Intel Corporation: Unknown device 4d44 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at ef80 [size=32] :00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio (rev 04) Subsystem: Intel Corporation: Unknown device 4d44 Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at e800 [size=256] I/O ports at ef00 [size=64] :01:00.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] (rev 15) (prog-if 00 [VGA]) Subsystem: Palit Microsystems Inc. Palit Microsystems Daytona TNT2 M64 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11 Memory at fd00 (32-bit, non-prefetchable) [size=16M] Memory at f200 (32-bit, prefetchable) [size=32M] Expansion ROM at fe9f [disabled] [size=64K] Capabilities: available only to root :02:0a.0 Communication controller: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01) Subsystem: LSI Logic / Symbios Logic 2P0S (2 port parallel adaptor) Flags: medium devsel, IRQ 11 I/O ports at dff0 [size=8] I/O ports at dfe0 [size=8] I/O ports at dfa8 [size=8] I/O ports at dfa0 [size=8] I/O ports at df98 [size=8] I/O ports at df80 [size=16] :02:0b.0 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) Subsystem: Belkin Root Hub Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at feafd000 (32-bit, non-prefetchable) [size=4K] Capabilities: available only to root :02:0b.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) Subsystem: Belkin Root Hub Flags: bus master, medium devsel, latency 32, IRQ 9 Memory at feafe000 (32-bit, non-prefetchable) [size=4K] Capabilities: available only to root :02:0b.2 USB Controller: NEC Corporation USB 2.0 (rev 04) (prog-if 20 [EHCI]) Subsystem: Belkin Root Hub Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at feaffc00 (32-bit, non-prefetchable) [size=256] Capabilities: available only to root :02:0d.0 Communication controller: Conexant HCF 56k Data/Fax/Voice/Spkp Modem (rev 08) Subsystem: Conexant HCF 56k Data/Fax/Voice/Spkp Modem Flags: bus master,
Re: [Emc-users] Unexpected realtime delay
The odd time stamp was due to me rebooting the PC. There is no cut'n'paste error. I t is exactly as it appeared. The big question on your response - You said (sse below) : Before running emc, try `sudo rmmod pcspkr` - That particular module is known to cause problems with some hardware/config combinations. Why would one do 'sudo rmmod pcspkr' if it is known to cause problems? I hope you don't misunderstand me - I'm only trying to understand what I need to do. Jack Ensor On Friday 09 March 2007 14:41, Jack Ensor wrote: [ 516.200256] 43867: ERROR: Unexpected realtime delay: check dmesg for details.[ 516.200263] Very odd - There is a timestamp that appears to be younger than the one at the beginning of the line... [ 516.200265] In recent history there were [ 516.200267] 1577520, 1577520, 1577656, 1577396, and 1577460 [ 516.200269] eThis time, there were 1893236 which is so anomalously [ 516.200282] large that it probably si And the output still looks truncated - Unless it was a cut'n'paste error, I would say the kernel log buffer is being hosed. [EMAIL PROTECTED]:~$ sudo /sbin/lsmod snip Way too many modules loaded that are not needed and probably not used. vfat, fat, bluetooth, rfcomm - With parport support being deliberately broken, loading of lp ppdev shouldn't be happening.. Before running emc, try `sudo rmmod pcspkr` - That particular module is known to cause problems with some hardware/config combinations. Regards, Paul. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Unexpected realtime delay
Jack Ensor wrote: The odd time stamp was due to me rebooting the PC. There is no cut'n'paste error. I t is exactly as it appeared. The big question on your response - You said (sse below) : Before running emc, try `sudo rmmod pcspkr` - That particular module is known to cause problems with some hardware/config combinations. Why would one do 'sudo rmmod pcspkr' if it is known to cause problems? Because rmmod is the program that removes modules from the running kernel. If there's a problem with a module, you remove it. You need sudo because that's how a normal user gets to run system administration commands like rmmod. In general, you can get help on any installed command by running man in a terminal (man command, without the quotes, will give you information on command (which, if you type it exactly, will probably say No manual entry for command, because there's no program called command)). One of the best things you can do with a new system is learn how to get help from the system. There's pretty good documentation in the manpages, which is also browseable from the GUI (the ? icon on the top taskbar), and also on the web (google for man rmmod and you'll get more information than you want). I hope you don't misunderstand me - I'm only trying to understand what I need to do. Jack Ensor Yep - it can be hard at first, but you'll get the hang of it. - Steve - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Unexpected realtime delay
Perhaps it helps to know what 'rmmod' does: $ man rmmod rmmod(8) NAME rmmod — simple program to remove a module from the Linux Kernel [... much more information snipped ...] Jeff - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
