Re: TCP/IP Plumbing Evolution

On Fri, Aug 31, 2007 at 03:38:19PM -0700, Garrett D'Amore wrote:
> Actually, I think what happened is that the world switched to AES.

That'd explain it too.

> I suspect the SCA 4000 3DES performance is probably *still* faster than
> typical commodity CPUs.  (Certainly than SPARCs.)

When the SCA 4k shipped, the DES/3DES IPsec was using was hardly optimized.
I wonder how EF's DES/3DES would hold up against an SCA 4k?

> The SCA 4000 had either no or greatly reduced AES performance.  (I don't
> recall whether the final version had a 5823 on it or not... we certainly
> had talked about it.)

It had no AES in it, AFAIK.

Dan

Re: TCP/IP Plumbing Evolution

On Fri, 2007-08-31 at 21:24 -0400, Dan McDonald wrote:
> On Fri, Aug 31, 2007 at 03:38:19PM -0700, Garrett D'Amore wrote:
> > Actually, I think what happened is that the world switched to AES.
> 
> That'd explain it too.
> 
> > I suspect the SCA 4000 3DES performance is probably *still* faster than
> > typical commodity CPUs.  (Certainly than SPARCs.)
> 
> When the SCA 4k shipped, the DES/3DES IPsec was using was hardly optimized.
> I wonder how EF's DES/3DES would hold up against an SCA 4k?

We compared it to highly optimized hand tuned 3DES code.  (Ferenc's
implementation, which is AFAIK what is in EF.)

> 
> > The SCA 4000 had either no or greatly reduced AES performance.  (I don't
> > recall whether the final version had a 5823 on it or not... we certainly
> > had talked about it.)
> 
> It had no AES in it, AFAIK.

That sounds right.

Thanks,

	-- Garrett

> 
> Dan

Solaris sever not responding INIT-ACK for INIT

Hi,
    solaris server is not responding with INIT_Ack for INIT it recieve from client after poer of /power on.

  we have 10 SCTP connections towards servers after power off/power on only 4 get associations get estd after
20 mints another 2 but remaing never get INIT -ACK from solaris .Can i know whats might be problem is there
anyway to debug this .

 
This message posted from opensolaris.org

Re: Solaris sever not responding INIT-ACK for INIT

Please find ethereal for the same problem i reported

 
This message posted from opensolaris.org

Please find ethereal for the same problem i reported

 
This message posted from opensolaris.org

Re: Solaris sever not responding INIT-ACK for INIT

Satish wrote:

>Hi,
>    solaris server is not responding with INIT_Ack for INIT it recieve from client after poer of /power on.
>
>  we have 10 SCTP connections towards servers after power off/power on only 4 get associations get estd
after 20 mints another 2 but remaing never get INIT -ACK from solaris .Can i know whats might be problem is
there anyway to debug this
>  
>

If your question/problem relates to Solaris 8, Solaris 9 or Solaris 10,
please raise the topic in the Solaris Networking forum:
http://forum.java.sun.com/forum.jspa?forumID=903

Otherwise, please mention which build of OpenSolaris you are using.

Thanks,
Darren

Re: nemo mac_notify change (webrev)

Garrett D'Amore wrote:
> I'm planning on putting back the fixes in the following webrev.  This
> changes the notification in Nemo somewhat, hopefully to be a lot more
> robust.
> 
> It fixes in particular 6508900, which basically states that i_mac_notify
> can fail, and when it does, it spams the log.  (Worse, it can fail to
> call qenable() which could lead to an apparent hang on transmit, etc.)
> 
> (It can fail due to resource shortage.)  My solution is to use a
> separate thread, bit mask, and condition variable.
> 
> The webrev is at http://cr.opensolaris.org/~gdamore/mac-notify/
> 
> Have a look if you're interested.  (I think I have my 2 needed
> reviewers, but I won't complain if others give me feedback.)
> 
> 	-- Garrett
> 
Garrett,

I had a look of your change, and I have several questions:

- What prevent new mac notifications come in between Line 1429 and Line 
1441? If new mac notifications can come in, the thread will exit because the 
check on Line 217 would passes, then the system will wait for ever on Line 
1444-1445?

I think more reasonable way is for i_mac_notify() to do nothing if ((bits & 
(1 << MAC_NNOTE)) != 0), and to have i_mac_notify_thread() to only exit 

Re: Solaris sever not responding INIT-ACK for INIT

Hi,
     Iam using solaris10.

 
This message posted from opensolaris.org

Re: nemo mac_notify change (webrev)

On Mon, 2007-09-03 at 16:50 +0800, Cathy Zhou wrote:
> Garrett D'Amore wrote:
> > I'm planning on putting back the fixes in the following webrev.  This
> > changes the notification in Nemo somewhat, hopefully to be a lot more
> > robust.
> > 
> > It fixes in particular 6508900, which basically states that i_mac_notify
> > can fail, and when it does, it spams the log.  (Worse, it can fail to
> > call qenable() which could lead to an apparent hang on transmit, etc.)
> > 
> > (It can fail due to resource shortage.)  My solution is to use a
> > separate thread, bit mask, and condition variable.
> > 
> > The webrev is at http://cr.opensolaris.org/~gdamore/mac-notify/
> > 
> > Have a look if you're interested.  (I think I have my 2 needed
> > reviewers, but I won't complain if others give me feedback.)
> > 
> > 	-- Garrett
> > 
> Garrett,
> 
> I had a look of your change, and I have several questions:
> 
> - What prevent new mac notifications come in between Line 1429 and Line 
> 1441? If new mac notifications can come in, the thread will exit because the 
> check on Line 217 would passes, then the system will wait for ever on Line 
> 1444-1445?

Its a good observation, but it is prevented because i_mac_notify checks

Re: CR 4296835 xxxxx, Now responsible manager P4 network/internet-uti"in.rwhod" lacks usable configuration

jim.j.moore@... wrote:
> 
> *Synopsis*: "in.rwhod" lacks usable configuration
> Due to a change of Responsible manager requested by xxxxx@...,
> xxxxx@... is now the responsible manager for:
> 
> CR 4296835 changed on Sep 3 2007 by xxxxx@...
> 
> === Field ============ === New Value ============= === Old Value =============
> 
> Responsible Manager    xxxxx@...               xxxxx@...
> Status                 4-Defer                     6-Fix Understood
> SubStatus              No Resource Available
> 
> ====================== =========================== ===========================

Erm... why ? AFAIK I filed the sponsor request long ago and I just
waiting that a sponsor somehow magically appears... the "resource" who
writes the patch is available...

----

Bye,
Roland

--

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@...
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090

Re: CR 4296835 xxxxx, Now responsible manager P4 network/internet-uti"in.rwhod" lacks usable configuration

Roland Mainz <roland.mainz@...> writes:

> jim.j.moore@... wrote:
>> 
>> *Synopsis*: "in.rwhod" lacks usable configuration
>> Due to a change of Responsible manager requested by xxxxx@...,
>> xxxxx@... is now the responsible manager for:
>> 
>> CR 4296835 changed on Sep 3 2007 by xxxxx@...
>> 
>> === Field ============ === New Value ============= === Old Value =============
>> 
>> Responsible Manager    xxxxx@...               xxxxx@...
>> Status                 4-Defer                     6-Fix Understood
>> SubStatus              No Resource Available
>> 
>> ====================== =========================== ===========================
>
> Erm... why ? AFAIK I filed the sponsor request long ago and I just
> waiting that a sponsor somehow magically appears... the "resource" who
> writes the patch is available...

I'd say the change should be reversed, and the bug keyworded
oss-request, if it isn't already.

(looking back through mail, it looks like you requested a sponsor for
a duplicate, maybe the keyword didn't get moved when the newer was
closed dup?)

-- Rich