Willem Jan Withagen wrote:
I'm looking for a stream exploder.:)
1 2Mbit stream in, and as many as possible out.
And 7*1Gb = 14Gbit, so I'd like to be pushing 7000 streams.
(One advantage is that they will be UDP streams, so there is
a little less bookkeeping in the protocol stack )
Wouldn't it
On Sun, Mar 02, 2008 at 03:58:50PM +0100, Luigi Rizzo wrote:
>
> The SI_ORDER_* definitions in /sys/sys/kernel.h are enumerated on a
> large range, so if the existing code does not have races,
> you can safely move the non-leaf modules
> (such as ipfw,ko in your case) to (SI_ORDER_ANY - some_small
Current FreeBSD problem reports
Critical problems
Serious problems
S Tracker Resp. Description
a kern/38554 netchanging interface ipaddress doesn't seem to work
s kern/39937 netipstealth
On Mon, Mar 03, 2008 at 11:17:19AM +0100, Paolo Pisati wrote:
> On Sun, Mar 02, 2008 at 03:58:50PM +0100, Luigi Rizzo wrote:
> >
> > The SI_ORDER_* definitions in /sys/sys/kernel.h are enumerated on a
> > large range, so if the existing code does not have races,
> > you can safely move the non-lea
Łukasz Bromirski wrote:
Willem Jan Withagen wrote:
I'm looking for a stream exploder.:)
1 2Mbit stream in, and as many as possible out.
And 7*1Gb = 14Gbit, so I'd like to be pushing 7000 streams.
(One advantage is that they will be UDP streams, so there is
a little less bookkeeping in the proto
Willem Jan Withagen wrote:
Łukasz Bromirski wrote:
Willem Jan Withagen wrote:
I'm looking for a stream exploder.:)
1 2Mbit stream in, and as many as possible out.
And 7*1Gb = 14Gbit, so I'd like to be pushing 7000 streams.
(One advantage is that they will be UDP streams, so there is
a little l
Łukasz Bromirski wrote:
My experience is that Multicast in nice in theory and experiment, but
when
push comes to shove it does not completely deliver.
I don't know exact requirements and application used, but given IP TV
deployments relying heavily on multicast, and all other "VoD"
technologie
Willem Jan Withagen wrote:
£ukasz Bromirski wrote:
Wouldn't it be a case for use of multicast vs unicast? Hardware
is always better anyway, so why not invest in some switch that
can do unicast/multicast in hardware?
Usefull suggestion, only this is going to be in an overlay cloud where
we do n
Synopsis: [bge] bge0: watchdog timeout -- resetting
State-Changed-From-To: feedback->open
State-Changed-By: gavin
State-Changed-When: Mon Mar 3 13:32:16 UTC 2008
State-Changed-Why:
Feedback was received - this is still an issue
Responsible-Changed-From-To: gavin->freebsd-net
Responsible-Changed
At 04:11 a.m. 03/03/2008, Mike Silbersack wrote:
Here's the same patch, but with the first ephemeral port changed
from 1024 to 1.
Now that I've actually gone to try to apply the patch (so I can view
the two codepaths side by side, rather than in diff form), I'm
finding that I can't apply
On Mon, 2008-03-03 at 13:54 +0100, Łukasz Bromirski wrote:
> I don't know exact requirements and application used, but given IP TV
> deployments relying heavily on multicast, and all other "VoD"
> technologies also using multicast...I find Your comments disturbing :)
>
> However, if you don't cont
Hi everybody,
I'have made a simple software load-balancer for FreeBSD. It work only in
direct-routing mode.
This is a kernel module that works for freebsd 6.2, 6.3 and 7.0 (tested)
(and netbsd soon). It use pfil in order to watch incoming packet and
redirect to real-server. You can define mu
At 04:43 a.m. 03/03/2008, Mike Silbersack wrote:
Earlier in the week, I had commented (via private e-mail?) that I
thought that Amit Klein's algorithm which I recently implemented in
ip_id.c might be adapted to serve as an ephemeral port
allocator. Now that I've thought more about it, I'm not
Hi all,
I am currently experiencing the same issue as well except this time around
with a Supermicro X7DBU motherboard (Intel® 5000P (Blackford) Chipset). The
identical occurence is happening to me as well so we were wondering if
anyone had a resolution? Possibly an updated driver for the Intel N
I am experiencing the exact same issue as well except this time around I do
not have an IPMI card and I am using the X7DBU motherboard by Supermicro.
Any luck?
Thanks,
Guy
Vladimir Ivanov wrote:
>
> Andrew Snow wrote:
>> Vladimir Ivanov wrote:
>>> We've same issue w/Supermicro boards if IPMI
At Fri, 29 Feb 2008 13:44:27 -0600,
Kevin Day wrote:
>
> This is from 7.0-RELEASE:
>
> lock order reversal:
> 1st 0xc3bde2b8 rtentry (rtentry) @ netinet6/nd6.c:1930
> 2nd 0xc3af367c radix node head (radix node head) @ net/route.c:147
> KDB: stack backtrace:
> db_trace_self_wrapper
> (c08af130
The fix to this problem is in the new shared code that got checked into
CURRENT on Friday. I will be MFCing the changes eventually but
if you want to test now you'll need to go with CURRENT.
On Mon, Mar 3, 2008 at 11:00 AM, Oznon <[EMAIL PROTECTED]> wrote:
>
> I am experiencing the exact same iss
Thanks for getting back to me so quickly Jack. Your response is very much
appreciated for it appears we will be testing with CURRENT for the time
being.
Cheers,
Guy
Jack Vogel wrote:
>
> The fix to this problem is in the new shared code that got checked into
> CURRENT on Friday. I will be MFC
On Mon, 3 Mar 2008, Fernando Gont wrote:
(Shame on me... somehow you mail got stuck in my queue, and I didn't respond
to it).
No sweat, I've taken far longer to reply to your e-mails!
While I haven't look match at the scheme proposed by Amit, I think there's a
"flaw" with the algorithm: IP
At a recent networking conference an IPv6 hour took place where IPv6
only was available. It was an interesting experience. On the whole,
things worked well, but I hit one problem.
When I brought up my system, I associated with the main conference SSID
and received an IPv6 address prior to the IPv6
On Mon, 3 Mar 2008, Fernando Gont wrote:
At 04:11 a.m. 03/03/2008, Mike Silbersack wrote:
Here's the same patch, but with the first ephemeral port changed from 1024
to 1.
Now that I've actually gone to try to apply the patch (so I can view the
two codepaths side by side, rather than i
At 03:23 a.m. 04/03/2008, Mike Silbersack wrote:
Too optimistic:
! #define IPPORT_EPHEMERALLAST 655535
Otherwise the patch looks good to me. It looked a bit strange in
unified diff format, I needed to look at it in context
format. (Strange, since I usually prefer unified.)
Doh! I had fi
At 03:37 a.m. 04/03/2008, Mike Silbersack wrote:
While I haven't look match at the scheme proposed by Amit, I think
there's a "flaw" with the algorithm: IP IDs need to be unique for
{source IP, des IP, Protocol}. And the algorithm still keeps a
*global* IP ID. That means you'll cycle through t
23 matches
Mail list logo
