From: <jb...@sp...> - 2007-01-23 09:20:53
|
Hi all I am having problems with the i2c-api implementation that comes with /projects/robostix/gumstix/ in the buildroot. I have a connex 400xm Gumstix and a Robostix. Have the revision 1198 image with i2c drivers added. I have stripped down my program to be running a read call to the robostix (I am to collect sensor data that is obtained by the robostix). In my test program I am reading 41 bytes at approx 50 Hz. I am running the fast mode on the i2c, 400kHz on the SCL. With a Oscilloscope I can see that the master (the gumstix) is doing almost all the clock stretching. When running the test program where the gumstix is doing nothing but reading at 50 Hz, the call looks like this: if (( rc =3D I2cReadBytes( i2cDev, 0x00, dummy_robo_packet, 41 )) !=3D 0 = ){ printf( "I2cReadByte failed: %d\n", rc ); return False; } When running this over some minutes the loadavg grows to about 1.60, this load can not be accepted since I am working on an autonomous control of a UAV. If I am reading only 1 byte instead of 41 bytes the load levels out on 0.69, which I also think is much. Changing back 100 kHz SCL produces 1.90 on loadavg. Can it really be true that it isn't possible to obtain this much data via the i2c bus. What can I do? Are there another i2c kernel driver/api I can use? Looking forward for your input --=20 Jakob Bj=F8rn |
From: Andrei R. <po...@gm...> - 2007-01-23 10:41:06
|
Hi Jackob, when I read 6 bytes of data over SPI bus at ~600 Hz I have the following load: PID USER STATUS RSS PPID %CPU %MEM COMMAND 2 root RWN 0 1 4.1 0.0 ksoftirqd/0 159 root SW< 0 6 3.3 0.0 pxa2xx-spi.2 ... That's ~7.4% CPU load! Actually in my case there are a few extra bytes I send back and forth to get these 6 bytes of data, but I would say that the numbers you're getting are somewhat similar (or better) than I'm getting with a completely different driver over different bus. The only possible way to improve performance is to mmap registers (so you could access them from 'userland' program, see pxaregs code for example) and optimize everything to your particular needs. -Andrei. On 1/23/07, Jakob Bj=F8rn <jb...@sp...> wrote: > Hi all > > I am having problems with the i2c-api implementation that comes with > /projects/robostix/gumstix/ in the buildroot. > > I have a connex 400xm Gumstix and a Robostix. Have the revision 1198 > image with i2c drivers added. > > I have stripped down my program to be running a read call to the > robostix (I am to collect sensor data that is obtained by the > robostix). In my test program I am reading 41 bytes at approx 50 Hz. I > am running the fast mode on the i2c, 400kHz on the SCL. With a > Oscilloscope I can see that the master (the gumstix) is doing almost > all the clock stretching. > > When running the test program where the gumstix is doing nothing but > reading at 50 Hz, the call looks like this: > > if (( rc =3D I2cReadBytes( i2cDev, 0x00, dummy_robo_packet, 41 )) !=3D = 0 ){ > printf( "I2cReadByte failed: %d\n", rc ); > return False; > } > > When running this over some minutes the loadavg grows to about 1.60, > this load can not be accepted since I am working on an autonomous > control of a UAV. If I am reading only 1 byte instead of 41 bytes the > load levels out on 0.69, which I also think is much. Changing back > 100 kHz SCL produces 1.90 on loadavg. > > Can it really be true that it isn't possible to obtain this much data > via the i2c bus. > > What can I do? Are there another i2c kernel driver/api I can use? > > Looking forward for your input > > -- > Jakob Bj=F8rn > |
From: Dave H. <dhy...@gm...> - 2007-01-23 15:26:37
|
Hi Jakob, > With a > Oscilloscope I can see that the master (the gumstix) is doing almost > all the clock stretching. What are you observing that leads you to believe that the gumstix is doing the clock stretching? > Can it really be true that it isn't possible to obtain this much data > via the i2c bus. Something else to keep in mind, is that the current code does CRC calculations on all of the data being sent/received. Rmoving the CRC calculations would reduce the CPU load on both sides. When obtainiing A/D samples, the sequence goes something like this: - host issues command - robostix receives command - robostix initiates A/D conversion - robostix waits for A/D conversion to complete (causes a clock stretch) - robostix sends back result >From a performance perspective, it would be much better to make the A/D conversion be interrupt driven and have the i2c just report back the result of the last conversion. > What can I do? Are there another i2c kernel driver/api I can use? How are you getting your program to run 50 times per second? Something to keep in mind. The load average is only sampled once every 5 seconds, and represents the number of active tasks at the sample time. The calculation of the load average takes place on a clock tick boundary. If your tasks are synchronized on a clock tick boundary, then you will get a skewed load. For example: Lets says I have a task that uses the CPU at the beginning of every clock tick. Regardless of how much CPU is actually being used, the load average would be reported as the same. You'd be much better off to measure CPU idle cycles. What you do is to point pm_idle (see arch/arm/process.c - look for the cpu_idle function) to your own idle function which simply increments a volatile counter in a continuous loop. You do a calibration to see how high it can count in one second. That gives you a baseline for 100% idle. Measuring idle CPU (and by deduction - active CPU) using this technique will give you a much better idea of how much CPU is really being used. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: <jb...@sp...> - 2007-01-23 15:27:57
|
A little follow up from the previous mail, I installed top on the gumstix (to compare Andrei's reply with my own) and was able to get the following insight.. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 248 root 15 0 1080 300 240 S 51.1 0.5 0:23.12 klogd 247 root 25 0 1080 316 244 R 47.5 0.5 0:22.70 syslogd 282 root 15 0 776 256 196 S 0.0 0.4 0:00.02 tester_20ms_sim It seems that it is not directly my program that is causing the immense load, but some kernel messaging functions (klogd, syslogd) is this understandable? Is there some way to disable these messages, the data i get from the i2c bus seems to be correct. Or maybe someone could point me in the direction of removing the occurrence of the messages altogether. I have not much experience in logs, which might also be apparent from the mail:) Should the following give me a clue on what to do, do I have to look somewhere else? [root@gumstix ~]# tail -f /var/log/messages Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: state:i2c_pxa_handler:868: ISR=3D00000085, ICR=3D000097e0, IBMR=3D00 Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: state:i2c_pxa_handler:868: ISR=3D00000085, ICR=3D000097e0, IBMR=3D00 Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: state:i2c_pxa_handler:868: ISR=3D00000085, ICR=3D000097e0, IBMR=3D00 .... there is a lot of these Does this make sense to anybody? /Jakob Bj=F8rn On 1/23/07, Andrei Rylin <po...@gm...> wrote: > Hi Jackob, > when I read 6 bytes of data over SPI bus at ~600 Hz > I have the following load: > PID USER STATUS RSS PPID %CPU %MEM COMMAND > 2 root RWN 0 1 4.1 0.0 ksoftirqd/0 > 159 root SW< 0 6 3.3 0.0 pxa2xx-spi.2 > ... > That's ~7.4% CPU load! > Actually in my case there are a few extra bytes I send back and forth > to get these 6 bytes of data, but I would say that the numbers > you're getting are somewhat similar (or better) than I'm getting with > a completely different driver over different bus. > The only possible way to improve performance is to mmap > registers (so you could access them from 'userland' program, > see pxaregs code for example) and optimize everything to your > particular needs. > -Andrei. > > On 1/23/07, Jakob Bj=F8rn <jb...@sp...> wrote: > > Hi all > > > > I am having problems with the i2c-api implementation that comes with > > /projects/robostix/gumstix/ in the buildroot. > > > > I have a connex 400xm Gumstix and a Robostix. Have the revision 1198 > > image with i2c drivers added. > > > > I have stripped down my program to be running a read call to the > > robostix (I am to collect sensor data that is obtained by the > > robostix). In my test program I am reading 41 bytes at approx 50 Hz. I > > am running the fast mode on the i2c, 400kHz on the SCL. With a > > Oscilloscope I can see that the master (the gumstix) is doing almost > > all the clock stretching. > > > > When running the test program where the gumstix is doing nothing but > > reading at 50 Hz, the call looks like this: > > > > if (( rc =3D I2cReadBytes( i2cDev, 0x00, dummy_robo_packet, 41 )) != =3D 0 ){ > > printf( "I2cReadByte failed: %d\n", rc ); > > return False; > > } > > > > When running this over some minutes the loadavg grows to about 1.60, > > this load can not be accepted since I am working on an autonomous > > control of a UAV. If I am reading only 1 byte instead of 41 bytes the > > load levels out on 0.69, which I also think is much. Changing back > > 100 kHz SCL produces 1.90 on loadavg. > > > > Can it really be true that it isn't possible to obtain this much data > > via the i2c bus. > > > > What can I do? Are there another i2c kernel driver/api I can use? > > > > Looking forward for your input > > > > -- > > Jakob Bj=F8rn > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > --=20 Jakob Bj=F8rn |
From: Dave H. <dhy...@gm...> - 2007-01-23 15:39:44
|
Hi Jakob, > Or maybe someone could point me in the direction of removing the > occurrence of the messages altogether. > > I have not much experience in logs, which might also be apparent from > the mail:) Should the following give me a clue on what to do, do I > have to look somewhere else? > > [root@gumstix ~]# tail -f /var/log/messages > Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: > state:i2c_pxa_handler:868: ISR=00000085, ICR=000097e0, IBMR=00 > Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: > state:i2c_pxa_handler:868: ISR=00000085, ICR=000097e0, IBMR=00 > Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: > state:i2c_pxa_handler:868: ISR=00000085, ICR=000097e0, IBMR=00 > .... > there is a lot of these > > Does this make sense to anybody? Ahh yes - printk's are considered a death knell to performance. Those printk's will only be enabled if the CONFIG_I2C_DEBUG_CORE option is enabled. Turn it off and rebuild the kernel. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2007-01-23 15:42:12
|
Whoops. > Ahh yes - printk's are considered a death knell to performance. Those > printk's will only be enabled if the CONFIG_I2C_DEBUG_CORE option is > enabled. Turn it off and rebuild the kernel. Actually, it appears to be CONFIG_I2C_DEBUG_BUSSES. Anyways for max performance you should turn off ALL DEBUG related stuff. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Andrei R. <po...@gm...> - 2007-01-23 18:14:45
|
Hi Jakob, I thought 1.6 load you reported was in %CPU - and it didn't seem overly unreasonable . Sorry about the confusion. Yeah, your close to %100 CPU is nothing but writing those log messages to a file... -Andrei. On 1/23/07, Jakob Bj=F8rn <jb...@sp...> wrote: > A little follow up from the previous mail, I installed top on the > gumstix (to compare Andrei's reply with my own) and was able to get > the following insight.. > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 248 root 15 0 1080 300 240 S 51.1 0.5 > 0:23.12 klogd > 247 root 25 0 1080 316 244 R 47.5 0.5 > 0:22.70 syslogd > 282 root 15 0 776 256 196 S 0.0 0.4 > 0:00.02 tester_20ms_sim > > It seems that it is not directly my program that is causing the > immense load, but some kernel messaging functions (klogd, syslogd) is > this understandable? Is there some way to disable these messages, the > data i get from the i2c bus seems to be correct. > > Or maybe someone could point me in the direction of removing the > occurrence of the messages altogether. > > I have not much experience in logs, which might also be apparent from > the mail:) Should the following give me a clue on what to do, do I > have to look somewhere else? > > [root@gumstix ~]# tail -f /var/log/messages > Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: > state:i2c_pxa_handler:868: ISR=3D00000085, ICR=3D000097e0, IBMR=3D00 > Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: > state:i2c_pxa_handler:868: ISR=3D00000085, ICR=3D000097e0, IBMR=3D00 > Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: > state:i2c_pxa_handler:868: ISR=3D00000085, ICR=3D000097e0, IBMR=3D00 > .... > there is a lot of these > > Does this make sense to anybody? > > /Jakob Bj=F8rn > > > > > > On 1/23/07, Andrei Rylin <po...@gm...> wrote: > > Hi Jackob, > > when I read 6 bytes of data over SPI bus at ~600 Hz > > I have the following load: > > PID USER STATUS RSS PPID %CPU %MEM COMMAND > > 2 root RWN 0 1 4.1 0.0 ksoftirqd/0 > > 159 root SW< 0 6 3.3 0.0 pxa2xx-spi.2 > > ... > > That's ~7.4% CPU load! > > Actually in my case there are a few extra bytes I send back and forth > > to get these 6 bytes of data, but I would say that the numbers > > you're getting are somewhat similar (or better) than I'm getting with > > a completely different driver over different bus. > > The only possible way to improve performance is to mmap > > registers (so you could access them from 'userland' program, > > see pxaregs code for example) and optimize everything to your > > particular needs. > > -Andrei. > > > > On 1/23/07, Jakob Bj=F8rn <jb...@sp...> wrote: > > > Hi all > > > > > > I am having problems with the i2c-api implementation that comes with > > > /projects/robostix/gumstix/ in the buildroot. > > > > > > I have a connex 400xm Gumstix and a Robostix. Have the revision 1198 > > > image with i2c drivers added. > > > > > > I have stripped down my program to be running a read call to the > > > robostix (I am to collect sensor data that is obtained by the > > > robostix). In my test program I am reading 41 bytes at approx 50 Hz. = I > > > am running the fast mode on the i2c, 400kHz on the SCL. With a > > > Oscilloscope I can see that the master (the gumstix) is doing almost > > > all the clock stretching. > > > > > > When running the test program where the gumstix is doing nothing but > > > reading at 50 Hz, the call looks like this: > > > > > > if (( rc =3D I2cReadBytes( i2cDev, 0x00, dummy_robo_packet, 41 )) != =3D 0 ){ > > > printf( "I2cReadByte failed: %d\n", rc ); > > > return False; > > > } > > > > > > When running this over some minutes the loadavg grows to about 1.60, > > > this load can not be accepted since I am working on an autonomous > > > control of a UAV. If I am reading only 1 byte instead of 41 bytes the > > > load levels out on 0.69, which I also think is much. Changing back > > > 100 kHz SCL produces 1.90 on loadavg. > > > > > > Can it really be true that it isn't possible to obtain this much data > > > via the i2c bus. > > > > > > What can I do? Are there another i2c kernel driver/api I can use? > > > > > > Looking forward for your input > > > > > > -- > > > Jakob Bj=F8rn > > > > > > > -----------------------------------------------------------------------= -- > > 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=3Djoin.php&p=3Dsourceforge&CID= =3DDEVDEV > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > -- > Jakob Bj=F8rn > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Jesse W. <jes...@gm...> - 2007-01-23 20:39:43
|
.......at 50hrz......on a journaled file system.... maybe this tidbit of info (debug is slow) should be wiki'd? On 1/23/07, Andrei Rylin <po...@gm...> wrote: > Hi Jakob, > I thought 1.6 load you reported was in %CPU - and it didn't seem overly > unreasonable . Sorry about the confusion. > Yeah, your close to %100 CPU is nothing but writing those > log messages to a file... > -Andrei. > > On 1/23/07, Jakob Bj=F8rn <jb...@sp...> wrote: > > A little follow up from the previous mail, I installed top on the > > gumstix (to compare Andrei's reply with my own) and was able to get > > the following insight.. > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 248 root 15 0 1080 300 240 S 51.1 0.5 > > 0:23.12 klogd > > 247 root 25 0 1080 316 244 R 47.5 0.5 > > 0:22.70 syslogd > > 282 root 15 0 776 256 196 S 0.0 0.4 > > 0:00.02 tester_20ms_sim > > > > It seems that it is not directly my program that is causing the > > immense load, but some kernel messaging functions (klogd, syslogd) is > > this understandable? Is there some way to disable these messages, the > > data i get from the i2c bus seems to be correct. > > > > Or maybe someone could point me in the direction of removing the > > occurrence of the messages altogether. > > > > I have not much experience in logs, which might also be apparent from > > the mail:) Should the following give me a clue on what to do, do I > > have to look somewhere else? > > > > [root@gumstix ~]# tail -f /var/log/messages > > Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: > > state:i2c_pxa_handler:868: ISR=3D00000085, ICR=3D000097e0, IBMR=3D00 > > Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: > > state:i2c_pxa_handler:868: ISR=3D00000085, ICR=3D000097e0, IBMR=3D00 > > Dec 31 16:00:28 gumstix user.debug kernel: i2c_adapter i2c-0: > > state:i2c_pxa_handler:868: ISR=3D00000085, ICR=3D000097e0, IBMR=3D00 > > .... > > there is a lot of these > > > > Does this make sense to anybody? > > > > /Jakob Bj=F8rn > > > > > > > > > > > > On 1/23/07, Andrei Rylin <po...@gm...> wrote: > > > Hi Jackob, > > > when I read 6 bytes of data over SPI bus at ~600 Hz > > > I have the following load: > > > PID USER STATUS RSS PPID %CPU %MEM COMMAND > > > 2 root RWN 0 1 4.1 0.0 ksoftirqd/0 > > > 159 root SW< 0 6 3.3 0.0 pxa2xx-spi.2 > > > ... > > > That's ~7.4% CPU load! > > > Actually in my case there are a few extra bytes I send back and forth > > > to get these 6 bytes of data, but I would say that the numbers > > > you're getting are somewhat similar (or better) than I'm getting with > > > a completely different driver over different bus. > > > The only possible way to improve performance is to mmap > > > registers (so you could access them from 'userland' program, > > > see pxaregs code for example) and optimize everything to your > > > particular needs. > > > -Andrei. > > > > > > On 1/23/07, Jakob Bj=F8rn <jb...@sp...> wrote: > > > > Hi all > > > > > > > > I am having problems with the i2c-api implementation that comes wit= h > > > > /projects/robostix/gumstix/ in the buildroot. > > > > > > > > I have a connex 400xm Gumstix and a Robostix. Have the revision 119= 8 > > > > image with i2c drivers added. > > > > > > > > I have stripped down my program to be running a read call to the > > > > robostix (I am to collect sensor data that is obtained by the > > > > robostix). In my test program I am reading 41 bytes at approx 50 Hz= . I > > > > am running the fast mode on the i2c, 400kHz on the SCL. With a > > > > Oscilloscope I can see that the master (the gumstix) is doing almos= t > > > > all the clock stretching. > > > > > > > > When running the test program where the gumstix is doing nothing bu= t > > > > reading at 50 Hz, the call looks like this: > > > > > > > > if (( rc =3D I2cReadBytes( i2cDev, 0x00, dummy_robo_packet, 41 ))= !=3D 0 ){ > > > > printf( "I2cReadByte failed: %d\n", rc ); > > > > return False; > > > > } > > > > > > > > When running this over some minutes the loadavg grows to about 1.60= , > > > > this load can not be accepted since I am working on an autonomous > > > > control of a UAV. If I am reading only 1 byte instead of 41 bytes t= he > > > > load levels out on 0.69, which I also think is much. Changing back > > > > 100 kHz SCL produces 1.90 on loadavg. > > > > > > > > Can it really be true that it isn't possible to obtain this much da= ta > > > > via the i2c bus. > > > > > > > > What can I do? Are there another i2c kernel driver/api I can use? > > > > > > > > Looking forward for your input > > > > > > > > -- > > > > Jakob Bj=F8rn > > > > > > > > > > ---------------------------------------------------------------------= ---- > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the chance to sha= re your > > > opinions on IT & business topics through brief surveys - and earn cas= h > > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CI= D=3DDEVDEV > > > _______________________________________________ > > > gumstix-users mailing list > > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > > -- > > Jakob Bj=F8rn > > > > -----------------------------------------------------------------------= -- > > 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=3Djoin.php&p=3Dsourceforge&CID= =3DDEVDEV > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > --=20 :wq |
From: Andrei R. <po...@gm...> - 2007-01-23 21:13:16
|
On 1/23/07, Jesse Welling <jes...@gm...> wrote: > .......at 50hrz......on a journaled file system.... > maybe this tidbit of info (debug is slow) should be wiki'd? Turning on debug option shall not produce that much noise unless something goes really bad or a user explicitly wants all that noise. |
From: Dave H. <dhy...@gm...> - 2007-01-23 21:48:58
|
Hi Andrei, On 1/23/07, Andrei Rylin <po...@gm...> wrote: > On 1/23/07, Jesse Welling <jes...@gm...> wrote: > > .......at 50hrz......on a journaled file system.... > > maybe this tidbit of info (debug is slow) should be wiki'd? > > Turning on debug option shall not produce that much noise > unless something goes really bad or a user explicitly wants all that noise. That particular debug causes a message to be printed for every single interrupt related to i2c, in addition to some other prints. You really only need that level of debug if you're trying to debug the i2c driver itself, in which case performance isn't that much of an issue. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Andrei R. <po...@gm...> - 2007-01-23 22:39:32
|
I2C_DEBUG_CORE is a generic debug option for i2c core. Even with this flag enabled i2c shall perform reasonably. IMHO it can print whatever amount of info about infrequent or abnormal things, like initialization, mode changes, shutdown, warnings etc. But to print something about every normal transaction there shall be a separate flag. Jakob would agree with me on that ;-) On 1/23/07, Dave Hylands <dhy...@gm...> wrote: > Hi Andrei, > > On 1/23/07, Andrei Rylin <po...@gm...> wrote: > > On 1/23/07, Jesse Welling <jes...@gm...> wrote: > > > .......at 50hrz......on a journaled file system.... > > > maybe this tidbit of info (debug is slow) should be wiki'd? > > > > Turning on debug option shall not produce that much noise > > unless something goes really bad or a user explicitly wants all that noise. > > That particular debug causes a message to be printed for every single > interrupt related to i2c, in addition to some other prints. You really > only need that level of debug if you're trying to debug the i2c driver > itself, in which case performance isn't that much of an issue. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > 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.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Dave H. <dhy...@gm...> - 2007-01-23 22:53:49
|
Hi Andrei, On 1/23/07, Andrei Rylin <po...@gm...> wrote: > I2C_DEBUG_CORE is a generic debug option for i2c core. > Even with this flag enabled i2c shall perform reasonably. > IMHO it can print whatever amount of info about infrequent or > abnormal things, like initialization, mode changes, shutdown, warnings etc. > But to print something about every normal transaction there shall be a > separate flag. > Jakob would agree with me on that ;-) Yeah, and as my second email poionted out, it's the CONFIG_I2C_DEBUG_BUSSES option that causes the extra printk's, not the CONFIG_I2C_DEBUG_CORE. Something else most people aren't aware of, printk's run with interrupts disabled, for the duration of the printk. If you print a 60 character message going to a 115200 kbaud link, then interrupts are disabled for 5 milliseconds while that print occurs. printk's also bypass the FIFO in the UART, so it has to wait until each character is sent out. This can cause serious performance degradation. It is possible to turn off printk's so that they don't go directly to the console, but rather go thru klogd and syslogd, and that can help alot, but then you don't necessarily see all of the printk'd output before a crash becuase you've introduced a buffer in the middle. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Andrei R. <po...@gm...> - 2007-01-23 23:14:15
|
I was trying to say that there's nothing to write a Wiki page about, the problem is with the code: BUSSES or CORE, they shall not flood your log for no reason. When I say "separate flag" I mean something like I2C_DEBUG_whatever_GET_LOTS_OF_CRAP_IN_YOUR_LOG Then people would surely know what to expect. On 1/23/07, Dave Hylands <dhy...@gm...> wrote: > Hi Andrei, > > On 1/23/07, Andrei Rylin <po...@gm...> wrote: > > I2C_DEBUG_CORE is a generic debug option for i2c core. > > Even with this flag enabled i2c shall perform reasonably. > > IMHO it can print whatever amount of info about infrequent or > > abnormal things, like initialization, mode changes, shutdown, warnings etc. > > But to print something about every normal transaction there shall be a > > separate flag. > > Jakob would agree with me on that ;-) > > Yeah, and as my second email poionted out, it's the > CONFIG_I2C_DEBUG_BUSSES option that causes the extra printk's, not the > CONFIG_I2C_DEBUG_CORE. > > Something else most people aren't aware of, printk's run with > interrupts disabled, for the duration of the printk. If you print a 60 > character message going to a 115200 kbaud link, then interrupts are > disabled for 5 milliseconds while that print occurs. printk's also > bypass the FIFO in the UART, so it has to wait until each character is > sent out. > > This can cause serious performance degradation. > > It is possible to turn off printk's so that they don't go directly to > the console, but rather go thru klogd and syslogd, and that can help > alot, but then you don't necessarily see all of the printk'd output > before a crash becuase you've introduced a buffer in the middle. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2007-01-23 23:20:58
|
Hi Andrei, On 1/23/07, Andrei Rylin <po...@gm...> wrote: > I was trying to say that there's nothing to write a Wiki page > about, the problem is with the code: > BUSSES or CORE, they shall not flood your log for no reason. > When I say "separate flag" I mean something like > I2C_DEBUG_whatever_GET_LOTS_OF_CRAP_IN_YOUR_LOG > Then people would surely know what to expect. Ahhh. Well I guess you would have to take that up with the original authors. I know that I normally use DEBUG flags in my own drivers and they can potentially output lots of stuff. They're intended to be used to debug the module and not for normal use. For now, the existing DEBUG flags should all be turned off if you want decent performance. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Andrei R. <po...@gm...> - 2007-01-24 05:34:48
|
It's all relative, your debug build may be used by others for their normal development. Not to praise the Diablo, just as an example: there's a company south of the border that ships debug version of much of their product to gazillion developers around the world. I'm sure a person there would get an earful if he or she decided to do excessive amount of debug output for no reason other than it's a debug build. On 1/23/07, Dave Hylands <dhy...@gm...> wrote: > Hi Andrei, > > On 1/23/07, Andrei Rylin <po...@gm...> wrote: > > I was trying to say that there's nothing to write a Wiki page > > about, the problem is with the code: > > BUSSES or CORE, they shall not flood your log for no reason. > > When I say "separate flag" I mean something like > > I2C_DEBUG_whatever_GET_LOTS_OF_CRAP_IN_YOUR_LOG > > Then people would surely know what to expect. > > Ahhh. > > Well I guess you would have to take that up with the original authors. > I know that I normally use DEBUG flags in my own drivers and they can > potentially output lots of stuff. They're intended to be used to debug > the module and not for normal use. > > For now, the existing DEBUG flags should all be turned off if you want > decent performance. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2007-01-24 06:22:00
|
Hi Andrei, On 1/23/07, Andrei Rylin <po...@gm...> wrote: > It's all relative, your debug build may be used by others for > their normal development. Not to praise the Diablo, just as > an example: there's a company south of the border that ships > debug version of much of their product to gazillion developers > around the world. I'm sure a person there would get an earful > if he or she decided to do excessive amount of debug output > for no reason other than it's a debug build. Yep - I agree with you completely, but apparently the i2c driver developers don't :) I tend to prefer allow runtime control to turn on and off various debug features. This makes it much easier to debug stuff in the field. At work, we also use circular log buffers and don't print stuff out so we can still maintain performance, and then dump the log out afterwards (and we typically patch the code that prints an oops to also dump out our buffer in case it crashes). -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: <jb...@sp...> - 2007-01-24 08:10:41
|
Hi and thanks I sure learned a lot from my own mistake here. I have had no use of the debug messages, I should just have followed the wiki more strictly. In fact I didn't know what I enabled where when I choose those flags. So my big lesson must be, to study the options more thoroughly before choosing. I am happy to have someone like you to fall back on, before yesterday I was ready to through out the I2C bus. Now it looks like we will be flying autonomous in June :) thanks all /Jakob On 1/24/07, Dave Hylands <dhy...@gm...> wrote: > Hi Andrei, > > On 1/23/07, Andrei Rylin <po...@gm...> wrote: > > It's all relative, your debug build may be used by others for > > their normal development. Not to praise the Diablo, just as > > an example: there's a company south of the border that ships > > debug version of much of their product to gazillion developers > > around the world. I'm sure a person there would get an earful > > if he or she decided to do excessive amount of debug output > > for no reason other than it's a debug build. > > Yep - I agree with you completely, but apparently the i2c driver > developers don't :) > > I tend to prefer allow runtime control to turn on and off various > debug features. This makes it much easier to debug stuff in the field. > > At work, we also use circular log buffers and don't print stuff out so > we can still maintain performance, and then dump the log out > afterwards (and we typically patch the code that prints an oops to > also dump out our buffer in case it crashes). > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > --=20 Jakob Bj=F8rn Fyensgade 18, 3.TH 9000 Aalborg Tlf: 29247429 |