Differences

This shows you the differences between two versions of the page.

--- devsummit:200511 [2005/11/19 19:38] – add info on Swiss plug EdMaste
+++ devsummit:200511 [2021/04/25 05:40] (current) – Move to DevSummit namespace. JethroNederhof
@@ Line 1: / Line 1: @@
-The %%FreeBSD%% Developer Summit associated with %%EuroBSDCon%% 2005 is occurring on Thursday, November 24 and Friday, November 25 2005, prior to the %%EuroBSDCon%% conference technical track.  The second day of the developer summit overlaps with the conference tutorial track.  The Developer Summit is a by-invitation event; please contact Max Laier for more information.
+====== Introduction ======
+The %%FreeBSD%% Developer Summit associated with %%EuroBSDCon%% 2005 was occurring on Thursday, November 24 and Friday, November 25 2005, prior to the %%EuroBSDCon%% conference technical track.
+====== Schedule ideas ======
+**We will have projectors if you want to prepare slides.**
-Thursday we will have lunch at the university cafeteria.  Vera reserved a table for 20 +/- some.  Food is available for 10,- CHF (7,- CHF if you can provide student-id).
+----
-On Friday we will join the tutorial crowd at a restaurant.  Menu is 18,- CHF (non-alcoholic drinks included) and we were asked to precollect the money in order to make payment easier.
-Note that Switzerland's AC plug is different than other places in Europe: [http://en.wikipedia.org/wiki/Domestic_AC_power_plugs_&_sockets#Type_J_.28Swiss_3-pin.29 Swiss 3 pin AC plug].
-PHK does a tutorial friday morning.  Many other attendees arrive during the day on Thursday.
-We will hold the summit at the "Regenzzimmer" in the university ([http://map.search.ch/basel/petersplatz-1 map including public transport]).  To get there you enter the university building at the main entrance "Petersplatz 1" go up the stairs (big stairway, hard to miss).  On the upper level it's just 3 meters straight from the head of the stairs and there should be a sign as well.
-Schedule ideas here:
 Silby wishes to spend some time talking about how students interact with Fedora / other Linux distros and how this impacts %%FreeBSD%%.
@@ Line 36: / Line 29: @@
 minutes - Interface groups, implications for sockets, jails and (policy) routing.  (andre)
+====== Actual Turnout ======
+Thursday:
+Friday:
+Silby did his Fedora presentation, pointing out things we should think about.  Slides?
+Chuck Lever gave a high-level overview of NFSv4 and the state of current implementations.  Slides?
+Poul-Henning gave a detailed explanation of the state of our time infrastructure.  TSC vs. ACPI-fast and why/how the TSC should be used for scheduling/accounting.  A Proof-Of-Concept patch has been sent to -current: http://lists.freebsd.org/pipermail/freebsd-current/2005-November/058510.html
+After lunch we split into groups.
+Network group log (provided by Silby):
+Network BOF:
+Started around 2:40pm
+Topics to discuss:
+  * tcpsecure changes
+  * tcp callout improvements
+  * stack virtualization vs interface groups
+  * lockless pfil
+  * routing table already covered
+  * network stack device driver API
+  * polling
+  * run to completion, other performance stuff
+  * MD5 checks
+  * tcpdump-like logging for weird packets
+Notes:
+Silby is working on tcp sequence numbers, timestamps
+Max brings up MD5 verification, we don't think we implement it fully yet
+Andre's working on:
+  * T/TCP version 2
+    * uses a session cookie, which can secure sessions
+    * the cookie also allows subsequent connections to skip the 3WHS
+Max on PFIL
+  * hacked up shared lock used by the packet filters
+  * a few implementations already, but no decision yet on which is best
+    * linear array
+    * singly linked list
+  * general lockless updates would be nice
+  * Most recent idea/implementation here: http://people.freebsd.org/~mlaier/pfil_lockless_20051204.diff
+Andre
+  * Atomic ops may be better than locks for an interface queue
+Ed:
+  * device polling
+  * locking wasn't correct until recently
+  * only applies to network devices (would be good to extend)
+  * no feedback from poll handlers telling how much work was done
+  * falls down when you hit 100% cpu usage
+  * done per network device instance right now
+  * SMP issues all resolved, wasn't actually a problem on 4.x SMP anyway
+  * firewire might be something else that could use it
+  * is interrupt moderation a good thing to add? - maybe, if possible - linux does it
+  * real time data acquisition might want polling as well
+silby:
+  * tcpsecure discussion
+  * RST solution we have is fine - tcpsecure's is bad
+  * SYN solution from tcpsecure seems good
+  * data injection protection seems to make sense
+  * andre/silby will try to open a constructive dialog with the tcpm working group
+andre:
+  * we need empirical evidence of what tcp problems (out of order, etc) are happening
+    * Data collectors at yahoo?
+silby:
+  * kernel tcpdump-like
+  * pflog can be used for this
+  * queue of packets over the past few seconds
+silby/andre:
+  * no empircal data yet
+  * optimization: one callout per socket
+  * rework callout wheel entirely
+    * locking is one problem
+    * hash-based nature of it is another
+    * scales to accuracy of hz, we don't need that accuracy
+    * change the time of a callout, but leave it in the same bucket move it to the correct bucket later
+      * has potential
+andre/se:
+  * should we delay acks at all?
+silby/andre:
+  * dragonfly acks all packets that arrived in one batch with only one ack
+    * more data needed before changing this
+andre:
+  * dynamic tcp socket buffers
+silby:
+  * reduce delayed ack time
+  * to 3*rtt?
+  * to 3*inter-packet time?
+  * tcp retransmit timeouts - do they need tuning for modern networks?
+andre:
+  * bw delay products for various networks
+andre:
+  * stack virualization vs interface groups
+  * virtualization causes nearly everything to be virtualized
+  * interface groups help with
+    * better jails
+    * policy routing
+  * research uses may be better served by virtualization for simulation purposes
+  * does xen buy the same research options?
+  * one use of vimage would be to make routing changes, then switch the stack atomically
+andre:
+  * openBGPD might be ported
+long xen/vmware discussion
+  * maybe network performance can be optimized in vmware
+andre:
+  * M_EOR flag will be used by SCTP, so we can't just remove it.
+  * SCTP has a few different implementations
+    * the KAME seems to be out of date
+    * Linux has a possibly different version
+    * Solaris has it too, origin unknown
+silby:
+  * ephemeral port quick reuse due to port randomization
+  * bloom filters?
+  * list of most recently closed ports in a static array
+  * array of ports, timestamps of when they were most recently used
+  * we need to calculate out connection rate * # ports * desired recycled time to see what is acceptable
+:34pm - %%BoF%% breaks up