[lwip-devel] [patch #5785] Integrate SNMP initialization in tcpip.c

[Frédéric Bernon]

Follow-up Comment #13, patch #5785 (project lwip):

Just an alternative idea: most of "timestamp" features are implemented as
"unsigned int 64bits". With that, you can use it like "absolute" time (like
file times, "number of 100-nanosecond intervals since January 1, 1601"), or
relative time from boot time.

So, Solution #1, why not "u64_t sys_arch_get_time_now();" ? Is it a real
problem? If a target can provide a u64_t tickcount, it can  always use the
older system with timeout...

About SNMP problem. sysUpTime is defined like this:

http://www.faqs.org/rfcs/rfc1213.html "RFC 1213 - Management Information Base
for Network Management of TCP/IP-based internets:MIB-II" 

          sysUpTime OBJECT-TYPE
              SYNTAX  TimeTicks
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The time (in hundredths of a second) since the network
management portion of the system was last                     
re-initialized."
              ::= { system 3 }

http://www.faqs.org/rfcs/rfc1155.html "RFC 1155 - Structure and
identification of management information for TCP/IP-based internets"

 TimeTicks ::=
                      [APPLICATION 3]
                          IMPLICIT INTEGER (0..4294967295)

All that indicate that sysUpTime will overflow each ~497 days. Long, but not
infinite. So, Solution #2, if we use a u32_t tickcount (in milliseconds) to
get sysUptime, ok, it will overflow each ~49.7 days, but is it a real
problem? Most of time, SNMP supervisors only display this information, but
there's no processing on it...

Last, Solution #3, is perhaps to keep the actual sys_timeout solution, but
with another period. We could call snmp_inc_sysuptime only each 1000ms (by
example), write something like that:

void snmp_inc_sysuptime( u32_t inc)
{ sysuptime+=inc;
} 

Less accurate, but less overhead...


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?5785>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/