Re: svn commit: r215791 - stable/8/sys/netinet

2010-11-24 Thread Gleb Smirnoff
On Wed, Nov 24, 2010 at 06:11:53PM +1100, Bruce Evans wrote:
B  +++ stable/8/sys/netinet/if_ether.cWed Nov 24 05:37:12 2010
(r215791)
B  @@ -381,7 +381,7 @@ retry:
B int canceled;
B 
B LLE_ADDREF(la);
B  -  la-la_expire = time_second + V_arpt_down;
B  +  la-la_expire = time_second;
B canceled = callout_reset(la-la_timer, hz * V_arpt_down,
B arptimer, la);
B if (canceled)
B 
B 
B Isn't using non-monotic time for timeouts always wrong?

Sure it is wrong. I never payed attention to that fact that time_second
could be non-monotic. Is it non-monotic? I failed to understand kern_tc
code at first glance.

B There are lots of other time_second's in networkining code.  These
B still outnumber time_uptime's by about 68:41.  rtcock.c uses the weird
B expression time_second - time_uptime for metrics.  Since time_uptime
B is relative to boot time while time_second is relative to the Epoch,
B their difference is approximately the number of seconds since the
B Epoch, which is a very strange value which might nevertheless be
B useful for converting between monotonic expiry times and real expiry
B times, but I think it doesn't work even for that if the real time is
B stepped.
B 
B Bruce

-- 
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r215791 - stable/8/sys/netinet

2010-11-24 Thread Bruce Evans

On Wed, 24 Nov 2010, Gleb Smirnoff wrote:


On Wed, Nov 24, 2010 at 06:11:53PM +1100, Bruce Evans wrote:
B  +++ stable/8/sys/netinet/if_ether.c  Wed Nov 24 05:37:12 2010
(r215791)
B  @@ -381,7 +381,7 @@ retry:
B   int canceled;
B 
B   LLE_ADDREF(la);
B  -la-la_expire = time_second + V_arpt_down;
B  +la-la_expire = time_second;
B   canceled = callout_reset(la-la_timer, hz * V_arpt_down,
B   arptimer, la);
B   if (canceled)
B 
B
B Isn't using non-monotic time for timeouts always wrong?

 monotonic


Sure it is wrong. I never payed attention to that fact that time_second
could be non-monotic. Is it non-monotic? I failed to understand kern_tc
code at first glance.


Real time (time_second) can go backwards (or jump forwards too much)
if someone steps the the clock.  In kern_tc.c, time_uptime is implemented
as a purely monotonic clock which goes forward by 1 (second) approximately
every 1 second of real-real-time, while time_second is misimplemented
as essentially (boottime.tv_sec + time_uptime), where boottime is
bogusly changed (although the actual boot time didn't change) if someone
steps the realtime clock to fix drift in it, including for POSIX leap
seconds and resumes.  (Suspends stop the monotonic clock, and on resume
only the real time clock is advanced by much (by bogusly setting boottime
forwards so that (boottime.tv_sec + time_uptime) gives the correct real
time.)

Using real time is actually correct for some timeouts, mainly for long
ones.  E.g., ones for the next day shouldn't be 8 hours late because the
system was suspended overnight.

Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r215791 - stable/8/sys/netinet

2010-11-23 Thread Gleb Smirnoff
Author: glebius
Date: Wed Nov 24 05:37:12 2010
New Revision: 215791
URL: http://svn.freebsd.org/changeset/base/215791

Log:
  MFhead r214508:
Revert a small part of the r198301, that is entirely unrelated to the
r198301 itself. It also broke the logic of not sending more than one
ARP request per second, that consequently lead to a potential problem
of flooding network with broadcast packets.

Modified:
  stable/8/sys/netinet/if_ether.c

Modified: stable/8/sys/netinet/if_ether.c
==
--- stable/8/sys/netinet/if_ether.c Wed Nov 24 05:24:36 2010
(r215790)
+++ stable/8/sys/netinet/if_ether.c Wed Nov 24 05:37:12 2010
(r215791)
@@ -381,7 +381,7 @@ retry:
int canceled;
 
LLE_ADDREF(la);
-   la-la_expire = time_second + V_arpt_down;
+   la-la_expire = time_second;
canceled = callout_reset(la-la_timer, hz * V_arpt_down,
arptimer, la);
if (canceled)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r215791 - stable/8/sys/netinet

2010-11-23 Thread Bruce Evans

On Wed, 24 Nov 2010, Gleb Smirnoff wrote:


Log:
 MFhead r214508:
   Revert a small part of the r198301, that is entirely unrelated to the
   r198301 itself. It also broke the logic of not sending more than one
   ARP request per second, that consequently lead to a potential problem
   of flooding network with broadcast packets.

Modified:
 stable/8/sys/netinet/if_ether.c

Modified: stable/8/sys/netinet/if_ether.c
==
--- stable/8/sys/netinet/if_ether.c Wed Nov 24 05:24:36 2010
(r215790)
+++ stable/8/sys/netinet/if_ether.c Wed Nov 24 05:37:12 2010
(r215791)
@@ -381,7 +381,7 @@ retry:
int canceled;

LLE_ADDREF(la);
-   la-la_expire = time_second + V_arpt_down;
+   la-la_expire = time_second;
canceled = callout_reset(la-la_timer, hz * V_arpt_down,
arptimer, la);
if (canceled)



Isn't using non-monotic time for timeouts always wrong?

There are lots of other time_second's in networkining code.  These
still outnumber time_uptime's by about 68:41.  rtcock.c uses the weird
expression time_second - time_uptime for metrics.  Since time_uptime
is relative to boot time while time_second is relative to the Epoch,
their difference is approximately the number of seconds since the
Epoch, which is a very strange value which might nevertheless be
useful for converting between monotonic expiry times and real expiry
times, but I think it doesn't work even for that if the real time is
stepped.

Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org