on Fri, 11 Mar 2005 20:20:02 +0900 (JST), Noritoshi Demizu said:
>ack 4195629532 win 5792 (-)<- Original ACK
>ack 4195629532 win 6576 (+784) <- dup ACK (with window update)
>ack 4195629532 win 6576 (0)<- dup ACK
>ack 4195629532 win 7240 (+664)
FreeBSD side more chances to give duplicate ACKs to recover quicker.
For related curiousities, would you tell me if the FreeBSD a Uniprocessor
or multiprocessor?
--Mark Tinguely.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman
happen a lot.
--Mark Tinguely
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
from he server have window adjustments, so the
client does not treat them as duplicate ACKs coming from a packet
loss.
--Mark Tinguely
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any
gestion is to turn on the verbose debugging, it may shed
light on the multicast problem.
--Mark Tinguely
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
used tcpdump on the FreeBSD machine and/or a Windows Ethernet
snooper to verify multicast/IGMP traffic?
--Mark Tinguely [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, s
g 2001 version of current. I am not an expert to say whether
or not Forward Acknowledgements are necessary. I am sure this is a
good starting point for SACK.
--Mark Tinguely.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listin
isadvantage. These could be added pretty easily.
--Mark Tinguely.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
because of a wrapped snd_recover.
These variables should be kept more up to date.
--Mark Tinguely
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
rtual return address returned by the interrupt complete
code).
--mark tinguely
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
et errors that would cause more
even greater performance problems. I suggest you upgrade.
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
to mask off these bits
from the hash anyway?
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
e and the mailing
> list archives, and haven't come upon an answer.
yes, ARP resolves all speeds of Ethernet to IP. -current and 4.5-stable
as of this week, also support other size MACs like Arcnet too.
--mark tinguely
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe f
just a PS reminder that you need to put the IP/ports in network byte
order. appropriate htonl() and htons() must be used if the the values
are not already in network byte order. You may get away with not doing
this on a Sparc (or Alpha?) because of their endian is network byte
order.
--mark
> In order to understand the effect of reordering better,
>
> a)the value of "Fast Retransmit Threshold" in tcp_input.c is modified to 1
ouch, hopefully this is an isolated network.
> b)packets of the connection are distributed over 2 links.
>
> 1. Is it possible to have so many duplicate ac
ng the soft-changing of the link level address
compatiable with ethernet.
To answer your question, the foot work has been done for you.
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
nnel. mrouted(8) performs
this function and several other required tasks.
Are you trying to do something beyond tunneling multicast over
an IPv4 network, such as tunneling inside the DVMRP tunnel or PIM
network?
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
Sorry, I lost my negatives this morning ...
we can NOT do much about stale snd_recover, and would NOT happen very
easilly, NOR often.
initialization for the snd_recover TCPS_SYN_SENT and TCPS_SYN_RECEIVED
is a simple solution that can handle the simple case, and much more likely
case.
--m
nd_max,
but less likely. I have not caught this in a trace yet.
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
round to fund a good
rewrite...of course there is some competative advatange to do so only
for themselves.
time to go back to (my) reality...
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
in tcp_usr_connect() and tcp6_usr_connect() in sys/netinet/tcp_usrreq.c
in both FreeBSD 4.3 and -current is there a missing
tp = intotcpcb(inp);
call? It seems from my eyes that "tp" is not initialized.
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &q
> It seems there is a problem in our IP stack with regards to
> multicasting. The symptoms is the inability to send multicast packets on
> correctly configured sockets in the absence of a default (or,
> erroneously, multicast address being used) route.
I don't know if I am reading your quest
driver.
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
23 matches
Mail list logo
