[lm-sensors] dme1737 very slow read...

[lm-sensors] dme1737 very slow read...

[Eric Sandeen]

I was very happy to see dme1737 support added, thank you!  Now I can get
all the info out of my compaq sr1710nx cheapo server.  :)

It all works - I did notice, though, that when I run "sensors" it's very
slow to read the sysfs file:

write(1, "Adapter: SMBus PIIX4 adapter at "..., 37) = 37 <0.000055>
open("/sys/class/i2c-adapter/i2c-0/0-002e/in0_input", O_RDONLY) = 3
<0.000032>
fstat(3, {st_mode=S_IFREG|0444, st_size@96, ...}) = 0 <0.000009>
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b7f69d6b000 <0.000014>
read(3, "0\n", 4096)                    = 2 <1.535188>

1.53 seconds to read "0\n" !  :)

Any idea if this is a hardware or software delay?  I haven't yet dug
into profiling the kernel code to see what might be taking so long...

Thanks,

-Eric

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] dme1737 very slow read...

[Juerg Haefliger]

Hi Eric,


> I was very happy to see dme1737 support added, thank you!  Now I can get
> all the info out of my compaq sr1710nx cheapo server.  :)

Glad you like it :-) I can finally tell my wife that the time I spent
on the driver wasn't all wasted...


> It all works - I did notice, though, that when I run "sensors" it's very
> slow to read the sysfs file:
>
> write(1, "Adapter: SMBus PIIX4 adapter at "..., 37) = 37 <0.000055>
> open("/sys/class/i2c-adapter/i2c-0/0-002e/in0_input", O_RDONLY) = 3
> <0.000032>
> fstat(3, {st_mode=S_IFREG|0444, st_size@96, ...}) = 0 <0.000009>
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0x2b7f69d6b000 <0.000014>
> read(3, "0\n", 4096)                    = 2 <1.535188>
>
> 1.53 seconds to read "0\n" !  :)
>
> Any idea if this is a hardware or software delay?  I haven't yet dug
> into profiling the kernel code to see what might be taking so long...

It's simple: We have to read a lot of registers which we can only get
to via I2C which is veeerrrrryyyyy sloooooowwwwww.

But you bring up an interesting issue. 1.53s is larger than the 1s
refresh rate of the driver. So the logic that prevents refreshes to
occur faster than every second is pretty much useless. I think I
should bump that value to at least 2s. Comments anyone?

...juerg


> Thanks,
>
> -Eric
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] dme1737 very slow read...

[Eric Sandeen]

Juerg Haefliger wrote:
> Hi Eric,
> 
> 
>> I was very happy to see dme1737 support added, thank you!  Now I can get
>> all the info out of my compaq sr1710nx cheapo server.  :)
> 
> Glad you like it :-) I can finally tell my wife that the time I spent
> on the driver wasn't all wasted...

I'm impressed; I tried to dislodge a data sheet for this chip from SMSC,
with no luck.  They don't want us to know our cpu temps it seems!  ;-)

>> 1.53 seconds to read "0\n" !  :)
>>
>> Any idea if this is a hardware or software delay?  I haven't yet dug
>> into profiling the kernel code to see what might be taking so long...
> 
> It's simple: We have to read a lot of registers which we can only get
> to via I2C which is veeerrrrryyyyy sloooooowwwwww.

Ok, I thought it might be along those lines.  Is there any other
performance impact to the system while it's waiting for the I2C bus?

Thanks,

-Eric

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] dme1737 very slow read...

[Juerg Haefliger]

Hi Eric,


> > Hi Eric,
> >
> >
> >> I was very happy to see dme1737 support added, thank you!  Now I can get
> >> all the info out of my compaq sr1710nx cheapo server.  :)
> >
> > Glad you like it :-) I can finally tell my wife that the time I spent
> > on the driver wasn't all wasted...
>
> I'm impressed; I tried to dislodge a data sheet for this chip from SMSC,
> with no luck.  They don't want us to know our cpu temps it seems!  ;-)

I only got it because the company I work for is under NDA with SMSC
even though I told them repeatedly that this is strictly for personal
use.


> >> 1.53 seconds to read "0\n" !  :)
> >>
> >> Any idea if this is a hardware or software delay?  I haven't yet dug
> >> into profiling the kernel code to see what might be taking so long...
> >
> > It's simple: We have to read a lot of registers which we can only get
> > to via I2C which is veeerrrrryyyyy sloooooowwwwww.
>
> Ok, I thought it might be along those lines.  Is there any other
> performance impact to the system while it's waiting for the I2C bus?

Good question, I don't know. That's more a question for the I2C
mailing list. Jean?

...juerg



> Thanks,
>
> -Eric
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] dme1737 very slow read...

[Juerg Haefliger]

Hi all,

On 7/25/07, Juerg Haefliger <juergh@gmail.com> wrote:
> Hi Eric,
>
>
> > I was very happy to see dme1737 support added, thank you!  Now I can get
> > all the info out of my compaq sr1710nx cheapo server.  :)
>
> Glad you like it :-) I can finally tell my wife that the time I spent
> on the driver wasn't all wasted...
>
>
> > It all works - I did notice, though, that when I run "sensors" it's very
> > slow to read the sysfs file:
> >
> > write(1, "Adapter: SMBus PIIX4 adapter at "..., 37) = 37 <0.000055>
> > open("/sys/class/i2c-adapter/i2c-0/0-002e/in0_input", O_RDONLY) = 3
> > <0.000032>
> > fstat(3, {st_mode=S_IFREG|0444, st_size@96, ...}) = 0 <0.000009>
> > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> > = 0x2b7f69d6b000 <0.000014>
> > read(3, "0\n", 4096)                    = 2 <1.535188>
> >
> > 1.53 seconds to read "0\n" !  :)
> >
> > Any idea if this is a hardware or software delay?  I haven't yet dug
> > into profiling the kernel code to see what might be taking so long...
>
> It's simple: We have to read a lot of registers which we can only get
> to via I2C which is veeerrrrryyyyy sloooooowwwwww.
>
> But you bring up an interesting issue. 1.53s is larger than the 1s
> refresh rate of the driver. So the logic that prevents refreshes to
> occur faster than every second is pretty much useless. I think I
> should bump that value to at least 2s. Comments anyone?

To answer my own question: Never mind :-) I just realized that the 1s
refresh rate is measured between the end of an update cycle and the
begining of a new cycle.

So all is good.

...juerg


> ...juerg
>
>
> > Thanks,
> >
> > -Eric
> >
> > _______________________________________________
> > lm-sensors mailing list
> > lm-sensors@lm-sensors.org
> > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> >
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] dme1737 very slow read...

[Mark M. Hoffman]

Hi:

* Juerg Haefliger <juergh@gmail.com> [2007-07-25 22:39:40 -0700]:
> > >> 1.53 seconds to read "0\n" !  :)
> > >>
> > >> Any idea if this is a hardware or software delay?  I haven't yet dug
> > >> into profiling the kernel code to see what might be taking so long...
> > >
> > > It's simple: We have to read a lot of registers which we can only get
> > > to via I2C which is veeerrrrryyyyy sloooooowwwwww.

Max rate for standard I2C/SMBus is 100KHz.  However, the hardware which is
most common on PCs usually runs at something like 10KHz.

> > Ok, I thought it might be along those lines.  Is there any other
> > performance impact to the system while it's waiting for the I2C bus?
> 
> Good question, I don't know. That's more a question for the I2C
> mailing list. Jean?

It depends on the specific I2C bus driver.  All of the most common ones use
polling, so unfortunately you will see CPU % go to 100 during that 1.5 sec.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] dme1737 very slow read...

[Jean Delvare]

Hi Mark, all,

On Thu, 26 Jul 2007 07:39:58 -0400, Mark M. Hoffman wrote:
> Max rate for standard I2C/SMBus is 100KHz.  However, the hardware which is
> most common on PCs usually runs at something like 10KHz.

Speed which our drivers don't even reach because they don't use
interrupts.

> > > Ok, I thought it might be along those lines.  Is there any other
> > > performance impact to the system while it's waiting for the I2C bus?
> > 
> > Good question, I don't know. That's more a question for the I2C
> > mailing list. Jean?
> 
> It depends on the specific I2C bus driver.  All of the most common ones use
> polling, so unfortunately you will see CPU % go to 100 during that 1.5 sec.

I don't think so. The I2C bus drivers sleep between polls, so most of
the time is spent sleeping. If we were "actively" polling (without
sleeping) it would be much faster, but would indeed suck the CPU time
so we don't do that.

Whoever is really concerned about slow I2C bus speed could spend some
time converting his/her I2C bus driver to use interrupts instead of
polling. I wanted to convert the i2c-i801 driver that way but could
never find the time for it.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] dme1737 very slow read...

[Mark M. Hoffman]

Hi Jean:

* Jean Delvare <khali@linux-fr.org> [2007-08-12 14:15:27 +0200]:
> Hi Mark, all,
> 
> On Thu, 26 Jul 2007 07:39:58 -0400, Mark M. Hoffman wrote:
> > Max rate for standard I2C/SMBus is 100KHz.  However, the hardware which is
> > most common on PCs usually runs at something like 10KHz.
> 
> Speed which our drivers don't even reach because they don't use
> interrupts.
> 
> > > > Ok, I thought it might be along those lines.  Is there any other
> > > > performance impact to the system while it's waiting for the I2C bus?
> > > 
> > > Good question, I don't know. That's more a question for the I2C
> > > mailing list. Jean?
> > 
> > It depends on the specific I2C bus driver.  All of the most common ones use
> > polling, so unfortunately you will see CPU % go to 100 during that 1.5 sec.
> 
> I don't think so. The I2C bus drivers sleep between polls, so most of
> the time is spent sleeping. If we were "actively" polling (without
> sleeping) it would be much faster, but would indeed suck the CPU time
> so we don't do that.
> 
> Whoever is really concerned about slow I2C bus speed could spend some
> time converting his/her I2C bus driver to use interrupts instead of
> polling. I wanted to convert the i2c-i801 driver that way but could
> never find the time for it.

You're right: for some reason I thought they were using mdelay, not msleep. 

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors