|
I just confirmed now why they shouldn't have gone this way and going everything through the CPLD... I was struggling to make CAN communication run smoothly. In our application, we have nearly 150 CAN messages on the bus every 500ms (TS7552 sends 26 and receives 121). I had problems because the other controllers on the network were regularly reporting communication timeouts. I started to time everything and found that sometimes buslock() calls can stall for several hundreds milliseconds... All hardware interfaces are going through the CPLD and use buslock(). For a test, I copied a file to the SDcard while our software is running and it made CAN communication completely erratic. Thats really not good... Design issue? --- In "Charles" <> wrote: > > > Hi -- > > --- In "Jean-Francois" jf@ wrote: > > > > Thanks for the clarifying this. Would there be an other and better way > > to deal reduce the 10ms minimum delay? I'm afraid that doing what I did > > could have a significant impact on performance. > > The BogoMIPS didn't bother. I just saw this as a sign that what I did > > was not entirely correct and could have other adverse effect. > > You are right, CONFIG_HZ has big effects. > > The 10mS delay is a FAQ here. Search this list for HRT (high resolution timers); it is a much better way of doing what you want, and gives nS resolution. I believe it is supported for cavium in the latest (-rc ?) mainline kernels, but it may be difficult to back-port to the TS-kernel. > > AFAIK, TS goal in putting the SD stuff in userspace and using nbd was to help insulate it from kernel changes, so maybe it would be easier to move to a vanilla kernel and forward port the TS SD stuff. At least you could see if TS met their goal .... > > As an aside, more than doubling your boot time by changing HZ to 1000 tells me there is a fundamental design issue somewhere. > > > regards .......... Charlie > > > > > --- In "Kris" <kristechnologic@> wrote: > > > > > > These are all artifacts from changing your kernel tick rate. The > > booting delay seen by SD card is because you are causing context > > switching to happen more often (every 1ms as opposed to 10ms) and since > > sdctl and nbd are userspace applications they can get switched out more > > if the dynamic scheduler of the kernel feels they are getting too much > > CPU time. > > > > > > The BoGoMIPS is calibrated based on the kernel tick I believe. They > > are a horribly measure of CPU speed anyway, and messing with the tick > > times 10 threw off the calculation times 10. > > > > > > -Kris Bahnsen > > > Technologic Systems > > > > > > > > > --- In JF Morneau jf@ wrote: > > > > > > > > With the default kernel, I can't get delays of less than 10ms. I > > > > increased the CONFIG_HZ from 100 to 1000 and I now can get sub 10ms > > delays. > > > > > > > > Timing in our program seems to work. I could verify from an external > > > > time source that a 2 ms delay is really 2 ms. However, our custom > > setup > > > > was booting in around 13 sec from sd. It now boots in 30 sec. I > > also > > > > noticed this change from dmesg: > > > > > > > > [ 0.020000] Calibrating delay loop (skipped)... 1916.92 BogoMIPS > > preset > > > > > > > > Before, it was: > > > > > > > > [ 0.010000] Calibrating delay loop (skipped)... 191.69 BogoMIPS > > preset > > > > > > > > It seems that there is more to it than just changing the CONFIG_HZ > > > > kernel config. > > > > > > > > > > __._,_.___
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required) Change settings via email: =Email Delivery: Digest | m("yahoogroups.com?subject","ts-7000-fullfeatured");=Change Delivery Format: Fully Featured">Switch to Fully Featured Visit Your Group | Yahoo! Groups Terms of Use | =Unsubscribe __,_._,___ |