Sqlnet tcp window

Are there any Oracle parameters that influence the TCP window size of a sqlnet connection?
Thanks in advance

Hi,
You can check this, may it help you
http://docs.oracle.com/cd/E11882_01/network.112/e10835/sqlnet.htm#BIIDDACA

Similar Messages

  • TCP Window sizing not working as expected for Windows server 2008 R2 SP1

    Hi ,
    TCP window size is not working as expected. It is varying . Aplied the hotfix suggested by Microsoft and set the multipliccation factor as 1.The window size is not getting auto tuned based on the client machine. The data transfer rate is getting degraded.
    Please help.
    Thanks,
    Pro1962

    Hi,
    I think window auto-tuning is enabled.
    You can disable it by running the following commend.
    netsh interface tcp set global autotuninglevel=disabled
    Hope this helps.

  • ACE default handling of the TCP Window Scale option

    Can someone tell me a reasonable explanation why the default action of the ACE is to clear the window-scale option in SYN-segments? We were long baffled why some customers (specifically the ones with larger latencies) were suffering from poor TCP transfer speeds and resets. Packet captures confirmed the fact that the ACE was clearing window-scale options, causing the advertised receive windows to be remarkably small as the scaling factors were removed.
    Isn't intermediate tampering with the window-scale option a widely known source for TCP performance problems? Window scaling is after all a widely used TCP extension. That's why I'm curious to know why such default behaviour from the ACE.
    Our problem was of course finally resolved by explicitly allowing the window-scale option using a parameter map.

    HI Timo,
    As you know if you allows the ACE to use a window scale factor that essentially increases the size of the TCP send and receive buffers. The sender specifies a window scale factor in a SYN segment that determines the send and receive window size for the duration of the connection.
    You have defined tcp-options scale allow in the parameter map but have not specified to which scale factor this should scale to.
    The TCP window scaling feature adds support for the Window Scaling option in RFC 1323. It is recommend that increasing the window size to improve TCP performance in network paths with large bandwidth, long-delay characteristics. This type of network is called a long fat network (LFN).
    But you have not configure a TCP window-scale factor which is essential for network paths with high-bandwidth, long-delay characteristics, using the "set tcp window-scale " command.
    The window scaling extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit window field of the TCP header.
    You can increase the window size to a maximum scale factor of 14.
    Typical applications use a scale factor of 3 when deployed in LFNs but in you case if this is a LFN you are using default which is 0.
    So here in your case you can select how much scale factor is needed to be defined from the range 0-14 , otherwise even if you have defined in the tcp-options windlow-scale allow, but as you have not define to what factor it should scale to , so it will always use the default scale factor which is 0, means no scaling at all.
    To set the TCP window-scale factor to 3, add the second command as well in your parameter map:
    host1/Admin(config-parammap-conn)# tcp-options window-scale allow        ---> Defined already
    host1/Admin(config-parammap-conn)# set tcp window-scale 3                      ----> Needed to be added else "default scale factor 0" will be taken
    You can check in the following URL at cisco docs wiki for how ACE handles Connection at Layer 4 (L4) and Layer 7 (L7):
    http://docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_(ACE)_Module_Troubleshooting_Guide,_Release_A2(x)_--_Troubleshooting_Connectivity
    Here are the details of how a tcp-options scale windows works:
    The window scale extension expands the definition of the TCP
    window to 32 bits and then uses a scale factor to carry this 32- bit
    value in the 16-bit Window field of the TCP header (SEG.WND in RFC-793).
    The scale factor is carried in a new TCP option, Window Scale.
    This option is sent only in a SYN segment (a segment with the SYN bit on),
    hence the window scale is fixed in each direction when a connection is opened.
    (Another design choice would be to specify the window scale in every TCP segment.
    It would be incorrect to send a window scale option only when the scale factor changed,
    since a TCP option in an acknowledgement segment will not be delivered reliably
    (unless the ACK happens to be piggy-backed on data in the other direction).
    Fixing the scale when the connection is opened has the advantage of lower
    overhead but the disadvantage that the scale factor cannot be changed
    during the connection.) The maximum receive window, and therefore the
    scale factor, is determined by the maximum receive buffer space.
    In a typical modern implementation, this maximum buffer space is set
    by default but can be overridden by a user program before a
    TCP connection is opened. This determines the scale factor,
    and therefore no new user interface is needed for window scaling.
    Window Scale Option The three-byte Window Scale option
    may be sent in a SYN segment by a TCP.
    It has two purposes:
    (1) indicate that the TCP is prepared to do both send and receive window scaling, and
    (2) communicate a scale factor to be applied to its receive window.
    Thus, a TCP that is prepared to scale windows should send the option,
    even if its own scale factor is 1. The scale factor is limited to
    a power of two and encoded logarithmically,
    so it may be implemented by binary shift operations.
    TCP Window Scale Option (WSopt):
    Kind: 3 Length: 3 bytes
    +---------+---------+---------+
    | Kind=3 |Length=3 |shift.cnt|
    +---------+---------+---------+
    This option is an offer, not a promise; both sides must send
    Window Scale options in their SYN segments to enable window
    scaling in either direction. If window scaling is enabled,
    then the TCP that sent this option will right-shift its true
    receive-window values by 'shift.cnt' bits for transmission in
    SEG.WND. The value 'shift.cnt' may be zero (offering to scale,
    while applying a scale factor of 1 to the receive window).
    This option may be sent in an initial segment (i.e., a
    segment with the SYN bit on and the ACK bit off).
    It may also be sent in a segment, but only if a Window
    Scale op- tion was received in the initial segment.
    A Window Scale option in a segment without a SYN bit should be ignored.
    The Window field in a SYN (i.e., a or ) segment itself is never scaled.
    Using the Window Scale Option
    A model implementation of window scaling is as follows
    All windows are treated as 32-bit quantities for storage in
    the connection control block and for local calculations.
    This includes the send-window (SND.WND) and the receive- window
    (RCV.WND) values, as well as the congestion window.
    * The connection state is augmented by two window shift counts,
    Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the
    incoming and outgoing window fields, respectively.
    * If a TCP receives a segment containing a Window Scale
    option, it sends its own Window Scale option in the segment.
    * The Window Scale option is sent with shift.cnt = R, where R
    is the value that the TCP would like to use for its receive window.
    * Upon receiving a SYN segment with a Window Scale option containing
    shift.cnt = S, a TCP sets Snd.Wind.Scale to S and sets Rcv.Wind.Scale
    to R; otherwise, it sets both Snd.Wind.Scale and Rcv.Wind.Scale to zero.
    * The window field (SEG.WND) in the header of every incoming segment,
    with the exception of SYN segments, is left-shifted by Snd.Wind.Scale
    bits before updating SND.WND: SND.WND = SEG.WND << Snd.Wind.Scale
    (assuming the other conditions of RFC793 are met,
    and using the "C" notation "<<" for left-shift).
    * The window field (SEG.WND) of every outgoing segment, with the
    exception of SYN segments, is right-shifted by
    Rcv.Wind.Scale bits: SEG.WND = RCV.WND >> Rcv.Wind.Scale.
    TCP determines if a data segment is "old" or "new" by testing
    whether its sequence number is within 2**31 bytes of the left
    edge of the window, and if it is not, discarding the data as "old".
    To insure that new data is never mistakenly considered old and vice- versa,
    the left edge of the sender's window has to be at most 2**31 away
    from the right edge of the receiver's window. Similarly with the
    sender's right edge and receiver's left edge. Since the right and
    left edges of either the sender's or receiver's window differ by
    the window size, and since the sender and receiver windows can be
    out of phase by at most the window size, the above constraints imply
    that
    2 * the max window size must be less than 2**31,
    or max window < 2**30 Since the max window is 2**S
    (where S is the scaling shift count) times at most 2**16 - 1
    (the maximum unscaled window),
    the maximum window is guaranteed to be < 2*30 if S <= 14.
    Thus, the shift count must be limited to 14 (which allows windows of 2**30 = 1 Gbyte).
    If a Window Scale option is received with a shift.cnt value exceeding 14,
    the TCP should log the error but use 14 instead of the specified value.
    The scale factor applies only to the Window field as transmitted
    in the TCP header; each TCP using extended windows will maintain
    the window values locally as 32-bit numbers. For example,
    the "congestion window" computed by Slow Start and Congestion Avoidance
    is not affected by the scale factor, so window scaling will not introduce
    quantization into the congestion window.
    Hope it will resolve your issue, else get back to us for further discussion.
    Best regards,
    Sachin Garg
    Message was edited by: sachinga.hcl

  • TCP Window Variation Sig fires repeatedly

    Sig 1307/0 TCP Window Variation is constantly firing on my IPS. The explanation mentions that some "improperly implemented" firewalls can cause this signature to fire. I have an ASA 5520 between my users and the internet and all internet traffic is NATed. It fires on normal web traffic to known good sites as well as traffic between sites coming in over IPSEC VPN, which is exempted from NAT. Any ideas on what may be causing this?

    This signature Sig 1307/0 will fire when the TCP window varies in a suspect manner. The right edge of the recieve window for TCP decreases. The TCP RFCs state that this should not occur.
    This signature will NOT function in promiscuous mode.
    Some incorrectly implemented proxies or network address translation firewalls could modify the window can cause this signature to fire.

  • ACE " tcp windows zero"

    I have one ACE configured in bridge mode. It is used to load balance between internet proxies.
    we also use sticky by source IP address. the internet is working fine with VIP and load is shared between the proxy servers.
    we have a problem with one side. it is Http side and also after authentication still be http .
    we can open that site if I used any of the proxies IP addresses as a proxy in my browser but when I use the VIP with my proxy setting the site page open and can not authenticate.
    when opening the home page of the site I will be redirected to one of teh proxy server ( sticky to my IP )  but after trying to authenticate I can not see any connection opened for my IP .
    I tried to sniff packet from my  PC I got ( tcp windows size zero )  and connection closed from the ACE.
    thanks in advance for your support

    Hi,
    May be
    CSCth39502
    Regards,

  • TCP Window Scaling supported on 3750G and 2960G switches?

    We have the 3750G with the IOS version 12.2(35)SE5. Does this IOS version and switch support the TCP Window Scaling detailed in this doc?  The doc says Release 12.2(8)T.  And I don't see the 3750G or the 2960G platforms listed in the doc. I'm guessing they're not but rather than guess, I thought I'd ask.  Thanks
    http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/tcpwslfn.pdf

    Disclaimer
    The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.
    Liability Disclaimer
    In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.
    Posting
    The doc says you may see better performance.
    Indeed you may, but the doc also notes "Do not use this command unless you clearly understand why you want to change the default value.".
    The two common situations where there's possible benefit to increasing the device's TCP receive window are:  to allow faster FTP/RCP downloads to the device or to support quicker BGP bulk transfers.  The former is limited by write speed to flash and the latter might be unusual to need > 64 KB for BDP.
    Also, BTW, if you do find a need to work with scaled TCP receive windows on a Cisco device, you probably also should enable (optional) SACK.

  • TCP Window Variation id=1307

    Hi, We are getting quite a lot of these alerts and I can't find any info. on the internet.  Can anyone shed any light on it..  There are hundreds of these alerts and most of the time the IP adresses are different.  As far as I can see most of the time the attacker ip address has been from inside address range.  Thanks. Regards
    evIdsAlert: eventId=1277786506114716833  vendor=Cisco  severity=high 
      originator:  
        hostId: abcips1 
        appName: sensorApp 
        appInstanceId: 414 
      time: Oct 06, 2011 05:26:59 UTC  offset=0  timeZone=GMT00:00 
      signature:   description=TCP Window Variation  id=1307  version=S212  type=anomaly  created=20030801 
        subsigId: 0 
        sigDetails: TCP Window varied in a suspect way 
        marsCategory: Info/Misc 
      interfaceGroup: vs0 
      vlan: 0 
      participants:  
        attacker:  
          addr: x.x.x.x  locality=OUT 
          port: 39825 
        target:  
          addr: x.x.x.x  locality=OUT 
          port: 5667 
          os:   idSource=learned  type=linux  relevance=relevant 
      riskRatingValue: 100  targetValueRating=medium  attackRelevanceRating=relevant 
      threatRatingValue: 100 
      interface: ge0_1 
      protocol: tcp 

    Thanks Mark. We do have an ASA as well as proxy (threat management gateway). I did see link that you posted before I posted my question but its not very clear from the article what can be done to resolve the problem.  It says "incorrectly configured" but in what way? It would have been nice if it gave us the possible solutions?  or what to check?  Thanks. Regards

  • TCP Window size

    Hi
    I captured some TCP comunication because there is a issue with long respons of some application.
    I see in some TCP packets using Wireshark:
    window size value:593
    {Calculated window size: 151808}
    {Window size scaling factor: 256}
    Can this values indicate some issue?
    Or is it correct?
    I have other capture when respons of application is OK and there is still the same value "window size value" and "Calculated window size"
    Thanks
    Peter

    Hi Peter,
    The Calculated window size: 151808 as shown above should be fine.
    As per RFC 1323:
    The TCP header uses a 16 bit field to report the receive
    window size to the sender.  Therefore, the largest window
    that can be used is 2**16 = 65K bytes.
    To circumvent this problem, Section 2 of this memo defines a
    new TCP option, "Window Scale", to allow windows larger than
    2**16.  This option defines an implicit scale factor, which
    is used to multiply the window size value found in a TCP
    header to obtain the true window size.
    Hope this helps.
    Thanks,
    Rajesh.

  • Windows TCP Socket Buffer Hitting Plateau Too Early

    Note: This is a repost of a ServerFault Question edited over the course of a few days, originally here: http://serverfault.com/questions/608060/windows-tcp-window-scaling-hitting-plateau-too-early
    Scenario: We have a number of Windows clients regularly uploading large files (FTP/SVN/HTTP PUT/SCP) to Linux servers that are ~100-160ms away. We have 1Gbit/s synchronous bandwidth at the office and the servers are either AWS instances or physically hosted
    in US DCs.
    The initial report was that uploads to a new server instance were much slower than they could be. This bore out in testing and from multiple locations; clients were seeing stable 2-5Mbit/s to the host from their Windows systems.
    I broke out iperf
    -s on a an AWS instance and then from a Windows client in the office:
    iperf
    -c 1.2.3.4
    [ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
    [ 5] 0.0-10.0 sec 6.55 MBytes 5.48 Mbits/sec
    iperf
    -w1M -c 1.2.3.4
    [ 4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
    [ 4] 0.0-18.3 sec 196 MBytes 89.6 Mbits/sec
    The latter figure can vary significantly on subsequent tests, (Vagaries of AWS) but is usually between 70 and 130Mbit/s which is more than enough for our needs. Wiresharking the session, I can see:
    iperf
    -c Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (*512) 
    iperf
    -c -w1M Windows SYN - Windows 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9
    Clearly the link can sustain this high throughput, but I have to explicity set the window size to make any use of it, which most real world applications won't let me do. The TCP handshakes use the same starting points in each case, but the forced one scales
    Conversely, from a Linux client on the same network a straight, iperf
    -c (using the system default 85kb) gives me:
    [ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
    [ 5] 0.0-10.8 sec 142 MBytes 110 Mbits/sec
    Without any forcing, it scales as expected. This can't be something in the intervening hops or our local switches/routers and seems to affect Windows 7 and 8 clients alike. I've read lots of guides on auto-tuning, but these are typically about disabling scaling
    altogether to work around bad terrible home networking kit.
    Can anyone tell me what's happening here and give me a way of fixing it? (Preferably something I can stick in to the registry via GPO.)
    Notes
    The AWS Linux instance in question has the following kernel settings applied in sysctl.conf:
    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    net.core.rmem_default = 1048576
    net.core.wmem_default = 1048576
    net.ipv4.tcp_rmem = 4096 1048576 16777216
    net.ipv4.tcp_wmem = 4096 1048576 16777216
    I've used dd
    if=/dev/zero | nc redirecting to /dev/null at
    the server end to rule out iperfand
    remove any other possible bottlenecks, but the results are much the same. Tests with ncftp(Cygwin,
    Native Windows, Linux) scale in much the same way as the above iperf tests on their respective platforms.
    First fix attempts.
    Enabling CTCP - This makes no difference; window scaling is identical. (If I understand this correctly, this setting increases the rate at which the congestion window is enlarged rather than the maximum size it can reach)
    Enabling TCP timestamps. - No change here either.
    Nagle's algorithm - That makes sense and at least it means I can probably ignore that particular blips in the graph as any indication of the problem.
    pcap files: Zip file available here: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Anonymised
    with bittwiste, extracts to ~150MB as there's one from each OS client for comparison)
    Second fix attempts.
    I've enabled ctcp and disabled chimney offloading: TCP Global Parameters
    Receive-Side Scaling State : enabled
    Chimney Offload State : disabled
    NetDMA State : enabled
    Direct Cache Acess (DCA) : disabled
    Receive Window Auto-Tuning Level : normal
    Add-On Congestion Control Provider : ctcp
    ECN Capability : disabled
    RFC 1323 Timestamps : enabled
    Initial RTO : 3000
    Non Sack Rtt Resiliency : disabled
    But sadly, no change in the throughput.
    I do have a cause/effect question here, though: The graphs are of the RWIN value set in the server's ACKs to the client. With Windows clients, am I right in thinking that Linux isn't scaling this value beyond that low point because the client's limited CWIN
    prevents even that buffer from being filled? Could there be some other reason that Linux is artificially limiting the RWIN?
    Note: I've tried turning on ECN for the hell of it; but no change, there.
    Third fix attempts.
    No change following disabling heuristics and RWIN autotuning. Have updated the Intel network drivers to the latest (12.10.28.0) with software that exposes functioanlity tweaks viadevice manager tabs. The card is an 82579V Chipset on-board NIC - (I'm going to
    do some more testing from clients with realtek or other vendors)
    Focusing on the NIC for a moment, I've tried the following (Mostly just ruling out unlikely culprits):
    Increase receive buffers to 2k from 256 and transmit buffers to 2k from 512 (Both now at maximum) - No change
    Disabled all IP/TCP/UDP checksum offloading. - No change.
    Disabled Large Send Offload - Nada.
    Turned off IPv6, QoS scheduling - Nowt.
    Further investigation
    Trying to eliminate the Linux server side, I started up a Server 2012R2 instance and repeated the tests using iperf (cygwin
    binary) and NTttcp.
    With iperf,
    I had to explicitly specify -w1m on both sides
    before the connection would scale beyond ~5Mbit/s. (Incidentally, I could be checked and the BDP of ~5Mbits at 91ms latency is almost precisely 64kb. Spot the limit...)
    The ntttcp binaries showed now such limitation. Using ntttcpr
    -m 1,0,1.2.3.5 on the server and ntttcp
    -s -m 1,0,1.2.3.5 -t 10 on the client, I can see much better throughput:
    Copyright Version 5.28
    Network activity progressing...
    Thread Time(s) Throughput(KB/s) Avg B / Compl
    ====== ======= ================ =============
    0 9.990 8155.355 65536.000
    ##### Totals: #####
    Bytes(MEG) realtime(s) Avg Frame Size Throughput(MB/s)
    ================ =========== ============== ================
    79.562500 10.001 1442.556 7.955
    Throughput(Buffers/s) Cycles/Byte Buffers
    ===================== =========== =============
    127.287 308.256 1273.000
    DPCs(count/s) Pkts(num/DPC) Intr(count/s) Pkts(num/intr)
    ============= ============= =============== ==============
    1868.713 0.785 9336.366 0.157
    Packets Sent Packets Received Retransmits Errors Avg. CPU %
    ============ ================ =========== ====== ==========
    57833 14664 0 0 9.476
    8MB/s puts it up at the levels I was getting with explicitly large windows in iperf.
    Oddly, though, 80MB in 1273 buffers = a 64kB buffer again. A further wireshark shows a good, variable RWIN coming back from the server (Scale factor 256) that the client seems to fulfil; so perhaps ntttcp is misreporting the send window.
    Further PCAP files have been provided, here:https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip
    Two more iperfs,
    both from Windows to the same Linux server as before (1.2.3.4): One with a 128k Socket size and default 64k window (restricts to ~5Mbit/s again) and one with a 1MB send window and default 8kb socket size. (scales higher)
    One ntttcp trace
    from the same Windows client to a Server 2012R2 EC2 instance (1.2.3.5). here, the throughput scales well. Note: NTttcp does something odd on port 6001 before it opens the test connection. Not sure what's happening there.
    One FTP data trace, uploading 20MB of /dev/urandom to
    a near identical linux host (1.2.3.6) using Cygwin ncftp.
    Again the limit is there. The pattern is much the same using Windows Filezilla.
    Changing the iperf buffer
    length does make the expected difference to the time sequence graph (much more vertical sections), but the actual throughput is unchanged.
    So we have a final question through all of this: Where is this limitation creeping in? If we simply have user-space software not written to take advantage of Long Fat Networks, can anything be done in the OS to improve the situation?

    Hi,
    Thanks for posting in Microsoft TechNet forums.
    I will try to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
    Thank you for your understanding and support.
    Kate Li
    TechNet Community Support

  • TCP Timeouts in Native Windows 7 64-bit (wired and wireless)

    I am having some major headaches with this new laptop in regards to network stability.  I have a W510 4318CTO with the Ultimate-N 6300 AGN adapter.  Here is what I'm seeing:
    Prior to installing Virtual PC/XP Mode, whenever I am browsing the web or accessing samba shares, I occasionally get spurts of timeouts.  Sometimes the timeouts are inescapable, but oddly enough the issue surfaces less after a hibernation than after a reboot or shutdown/start.  Google Docs is one thing that is especially unstable.  Either the icons don't load or the style sheet doesn't load or I can't click on anything or I can't save a document or open a document.  This happens across all browsers when run in regular old Windows 7.  I tried adjusting affinity and resetting tcp and reinstalling the network drivers and scanning for malware and yada yada yada.
    I have made queries on Microsoft Connect and TechSupportForum and nothing I've tried is helping.  This problem doesn't happen on my XP desktop at all, and very strangely, this doesn't happen in XP Mode on the same laptop at the same time as the issue surfaces in native win7.  If I ping the gateway, I get timeouts at the same time as the issue manifests and I get longer response times when making network requests.  I have been hammering this issue for the entire month and can't get past it.  I've tried uninstalling Lenovo's Access Connection tool and that didn't help either.   I tried this over the 82577LM gigabit wired adapter as well and have the same issues but they occur less than in wireless mode (which I would expect).
    I am quite an expert on Windows, but this issue has brought me to my wits end.  I am an inch away from blowing the preinstall away and starting from scratch, but I just don't want to invest so much time in reinstalling everything.  I've had enough trouble with working around power management issues on this new laptop and I just want this fixed.
    If you can solve this, I would be forever grateful.  I feel like I'm in the empty hell of a network admin's nightmare.
    - Steve

    Hello,
    If go into the Device Manager (filename: DEVMGMT.MSC), select View→Show Hidden Devices and examine the Non-Plug and Play Drivers tree, are there any old device drivers left over from previously installed security or connectivity software?  If so, perhaps one of those is the culprit and disabling or uninstalling it will solve the problem.
    Another possibility is that the automatic network tuning enhancements (a feature first introduced in Windows Vista) in Windows 7's network stack are changing the TCP window size until it reaches a value which is incompatible with your router.  That is fairly simple to test, though:  Open an elevated Command Prompt (filename: CMD.EXE) and issue a "netsh int tcp set global autotuninglevel=disabled" command and see if that makes any difference.  If that makes no difference, repeat the Netsh command with "autotuning=enabled" to restore the previous values and we can continue troubleshooting.
    Regards,
    Aryeh Goretsky
    I am a volunteer and neither a Lenovo nor a Microsoft employee. • Dexter is a good dog • Dexter je dobrý pes
    S230u (3347-4HU) • X220 (4286-CTO) • W510 (4318-CTO) • W530 (2441-4R3) • X100e (3508-CTO) • X120e (0596-CTO) • T61p (6459-CTO) • T43p (2678-H7U) • T42 (2378-R4U) • T23 (2648-LU7)
      Deutsche Community   Comunidad en Español Русскоязычное Сообщество

  • In AIR 3.x, a socket write()+flush() on a client will hang app if peer adverts TCP ZERO WINDOW

    In AIR 3.x, a socket write() + flush() on a client will hang (and freeze the entire app) if the socket peer advertises a ZERO TCP Window, i.e. no space available in peer receiver's socket buffer.
    AIR on Windows insists that the developer flush() the socket in order to write (any data at all).  When the peer (receiver) advertises a 0 byte tcp window, the client flush() call can sometimes take 10 seconds (i.e. 10000 milliseconds), whereas normally it should take 10 to 50 milliseconds.
    Additionally, AIR stayed in hung position.  Since the socket had TCP KEEPALIVE option enabled (at the server), the socket stayed open.  I let it stay hung overnight.  The next day when I rebooted the server, the socket got closed and finally the AIR program "RETURNED FROM the sock.flush()" call.  A timestamp before and after the call to flush() showed that the flush() call was in hung state for 56472475 milliseconds, i.e. 15.7 hours!  After it returned from the flush() call the AIR app was responsive and seemed to work properly.  Thus proving that it was indeed stuck (or blocked) on the flush() call for 15 hours trying to drain the data to a socket with zero tcp window condition.
    A tcp zero window condition on 1 socket hanging an entire app sounds concerning.
    Solution Suggestions:
    (1) What is needed is for the OutputProgress event to include a field for 'bytes that can be written safely without blocking on the socket', i.e. 'space available in underlying platform socket buffer' which would account for the socket send buffer size.
    (2) An alternative solution would be for AIR to provide a write-timeout setsockopt (or a writeTimeout() method on the socket), and return flush with an error (or EWOULDBLOCK), and call the OUTPUTPROG event only when there is enough space available.
    If there are any other workarounds, please let me know.
    Thank you.

    Question:  Does Adobe AIR expose the getsockopt() and setsockopt() calls on a socket?  It would be useful to apps to tune the io buffer sizes.
    Additional Details:
    RTT = 100+ milliseconds
    TCP Window Scaling enabled
    Secure Socket
    Hard to reproduce with plain TCP socket, but occurs without fail with SecureSocket.  Not knowing the underlying code base, am wondering if it is because the SSL encryption overhead (bytes) throws off the buffer available size compution in secure_sock.flush() .
    Thanks.

  • Non-global zone sending TCP SYN-ACK packet over wrong interface.

    After spending many hours looking at ipmon/ethereal logs, I believe I've found
    a explanation (a bug?) for the following strange behaviour (Solaris 10u1):
    I've got a non-global zone with Apache2 with dedicated IP and bound to interface e1000g2 of a Sun X4200 box. The global zone has a different dedicated IP bound to a different interface e1000g0.
    When I point a browser at the web site, the HTML page often comes up immediately, but sometimes it will hang and only load when I press the reload browser button one or multiple times. This is reproducible with different browsers from different networks with or without DNS resolution. It's reproducible with other non-local zones configured alike and running different TCP based services (namely SSH or non-Apache HTTP).
    This is what happens in a failing case (Ethereal client dump "dump_failed.txt" and IPF log "att1.txt" lines 1-3 pp): the incoming TCP SYN comes over interface e1000g2 (correct) and is passed by IPF. However, the non-global zone sends the TCP SYN-ACK package back over interface e1000g0, which is wrong and causes IPF to fail to build a correct state entry. Then, afterwards, the response packets from the webserver will be filtered by IPF, since it has no state entry.
    In the success case (Ethereal client dump "dump_success.txt" and IPF log "att1.txt" lines 19-21 pp), the incoming TCP SYN is answered correctly by a TCP SYN-ACK both over interface e1000g2. IPF can build a state entry and all subsequent packets from the webserver reach the client.
    =====
    The non-global zone has this setup:
    zonecfg:ws1> info
    ...snip...
    net:
    address: 62.146.25.34
    physical: e1000g2
    zonecfg:ws1>
    =====
    The relevant (as of the IPF log) IPF rules are:
    rule 1: block out log all
    rule 16: pass in log quick proto tcp from any to 62.146.25.34 port = 80 keep state
    =====
    If I didn't miss an important point, I suspect this to be a bug in Zones and/or IPF.
    Any hints?
    Thx,
    Tobias
    "att1.txt":
    LINE     PACKET_DT     PACKET_FS     PACKET_IFC     RULE_NUMBER     RULE_ACTION     SOURCE_IP     SOURCE_PORT     DEST_IP     DEST_PORT     PROTOCOL     TCP_FLAGS
    1     08.05.2006 21:24:09     786741     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     S
    2     08.05.2006 21:24:09     786863     e1000g0     16     p     62.146.25.34     80     84.56.16.159     60693     tcp     AS
    3     08.05.2006 21:24:09     808218     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     A
    4     08.05.2006 21:24:09     837170     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
    5     08.05.2006 21:24:09     837189     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    6     08.05.2006 21:24:09     837479     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AP
    7     08.05.2006 21:24:12     823801     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
    8     08.05.2006 21:24:12     823832     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    9     08.05.2006 21:24:13     210039     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AP
    10     08.05.2006 21:24:18     839318     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
    11     08.05.2006 21:24:18     839351     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    12     08.05.2006 21:24:19     970040     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AP
    13     08.05.2006 21:24:24     840073     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AF
    14     08.05.2006 21:24:30     870503     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
    15     08.05.2006 21:24:30     870538     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    16     08.05.2006 21:24:33     480059     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    17     08.05.2006 21:24:45     347464     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AF
    18     08.05.2006 21:24:45     347498     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    19     08.05.2006 21:24:47     857068     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     S
    20     08.05.2006 21:24:47     857118     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AS
    21     08.05.2006 21:24:47     878257     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     A
    22     08.05.2006 21:24:47     907630     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     AP
    23     08.05.2006 21:24:47     907644     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     A
    24     08.05.2006 21:24:47     907892     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AP
    25     08.05.2006 21:24:47     976361     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     AP
    26     08.05.2006 21:24:47     976375     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     A
    27     08.05.2006 21:24:47     976487     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AP
    28     08.05.2006 21:24:48     127599     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     A
    29     08.05.2006 21:24:54     932569     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AFP
    30     08.05.2006 21:24:54     932595     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    31     08.05.2006 21:25:00     490052     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    32     08.05.2006 21:25:02     980057     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AF
    33     08.05.2006 21:25:03     1890     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     A
    34     08.05.2006 21:25:09     907916     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     AF
    35     08.05.2006 21:25:09     907949     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     A
    36     08.05.2006 21:25:42     948502     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AFP
    37     08.05.2006 21:25:42     948535     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    38     08.05.2006 21:25:54     500051     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    39     08.05.2006 21:26:54     510046     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    40     08.05.2006 21:27:54     520041     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    41     08.05.2006 21:28:54     530040     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    42     08.05.2006 21:29:54     540039     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    43     08.05.2006 21:30:54     550039     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    44     08.05.2006 21:31:54     560041     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    "dump_failed.txt":
    No. Time Source Destination Protocol Info
    1 0.000000 192.168.1.101 62.146.25.34 TCP 1079 > http [SYN] Seq=0 Len=0 MSS=1460
    Frame 1 (62 bytes on wire, 62 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 48
    Identification: 0x0269 (617)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xde9d [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 0, Len: 0
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 0 (relative sequence number)
    Header length: 28 bytes
    Flags: 0x0002 (SYN)
    Window size: 65535
    Checksum: 0x5c3c [correct]
    Options: (8 bytes)
    No. Time Source Destination Protocol Info
    2 0.022698 62.146.25.34 192.168.1.101 TCP http > 1079 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
    Frame 2 (62 bytes on wire, 62 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 48
    Identification: 0x002f (47)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2ed8 [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1079 (1079), Seq: 0, Ack: 1, Len: 0
    Source port: http (80)
    Destination port: 1079 (1079)
    Sequence number: 0 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 28 bytes
    Flags: 0x0012 (SYN, ACK)
    Window size: 49368
    Checksum: 0xd017 [correct]
    Options: (8 bytes)
    No. Time Source Destination Protocol Info
    3 0.022749 192.168.1.101 62.146.25.34 TCP 1079 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
    Frame 3 (54 bytes on wire, 54 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x026a (618)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdea4 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
    Window size: 65535
    Checksum: 0x19dc [incorrect, should be 0xbdac]
    No. Time Source Destination Protocol Info
    4 0.022919 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
    Frame 4 (476 bytes on wire, 476 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 462
    Identification: 0x026b (619)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdcfd [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65535
    Checksum: 0x1b82 [incorrect, should be 0xcda5]
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    5 3.013084 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
    Frame 5 (476 bytes on wire, 476 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 462
    Identification: 0x0276 (630)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdcf2 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65535
    Checksum: 0x1b82 [incorrect, should be 0xcda5]
    SEQ/ACK analysis
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    6 9.029003 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
    Frame 6 (476 bytes on wire, 476 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 462
    Identification: 0x027f (639)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdce9 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65535
    Checksum: 0x1b82 [incorrect, should be 0xcda5]
    SEQ/ACK analysis
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    7 21.060827 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
    Frame 7 (476 bytes on wire, 476 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 462
    Identification: 0x0284 (644)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdce4 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65535
    Checksum: 0x1b82 [incorrect, should be 0xcda5]
    SEQ/ACK analysis
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    8 35.561984 192.168.1.101 62.146.25.34 TCP 1079 > http [FIN, ACK] Seq=423 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
    Frame 8 (54 bytes on wire, 54 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x029a (666)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xde74 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 423, Ack: 1, Len: 0
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0011 (FIN, ACK)
    Window size: 65535
    Checksum: 0x19dc [incorrect, should be 0xbc05]
    "dump_success.txt":
    No. Time Source Destination Protocol Info
    1 0.000000 192.168.1.101 62.146.25.34 TCP 1083 > http [SYN] Seq=0 Len=0 MSS=1460
    Frame 1 (62 bytes on wire, 62 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 48
    Identification: 0x02a3 (675)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xde63 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 0, Len: 0
    Source port: 1083 (1083)
    Destination port: http (80)
    Sequence number: 0 (relative sequence number)
    Header length: 28 bytes
    Flags: 0x0002 (SYN)
    Window size: 65535
    Checksum: 0x70ca [correct]
    Options: (8 bytes)
    No. Time Source Destination Protocol Info
    2 0.020553 62.146.25.34 192.168.1.101 TCP http > 1083 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
    Frame 2 (62 bytes on wire, 62 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 48
    Identification: 0x006b (107)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2e9c [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 0, Ack: 1, Len: 0
    Source port: http (80)
    Destination port: 1083 (1083)
    Sequence number: 0 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 28 bytes
    Flags: 0x0012 (SYN, ACK)
    Window size: 49368
    Checksum: 0xb530 [correct]
    Options: (8 bytes)
    No. Time Source Destination Protocol Info
    3 0.020599 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
    Frame 3 (54 bytes on wire, 54 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x02a4 (676)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xde6a [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
    Source port: 1083 (1083)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
    Window size: 65535
    Checksum: 0x19dc [incorrect, should be 0xa2c5]
    No. Time Source Destination Protocol Info
    4 0.020746 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
    Frame 4 (476 bytes on wire, 476 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 462
    Identification: 0x02a5 (677)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdcc3 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
    Source port: 1083 (1083)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65535
    Checksum: 0x1b82 [incorrect, should be 0xb2be]
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    5 0.071290 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=1 Ack=423 Win=49368 Len=0
    Frame 5 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x006c (108)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2ea3 [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 0
    Source port: http (80)
    Destination port: 1083 (1083)
    Sequence number: 1 (relative sequence number)
    Acknowledgement number: 423 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
    Window size: 49368
    Checksum: 0xe046 [correct]
    No. Time Source Destination Protocol Info
    6 0.075838 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 200 OK (text/html)
    Frame 6 (413 bytes on wire, 413 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 399
    Identification: 0x006d (109)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2d3b [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 359
    Source port: http (80)
    Destination port: 1083 (1083)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 360 (relative sequence number)
    Acknowledgement number: 423 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 49368
    Checksum: 0x29b8 [correct]
    Hypertext Transfer Protocol
    Line-based text data: text/html
    No. Time Source Destination Protocol Info
    7 0.095473 192.168.1.101 62.146.25.34 HTTP GET /favicon.ico HTTP/1.1
    Frame 7 (407 bytes on wire, 407 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 393
    Identification: 0x02aa (682)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdd03 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 423, Ack: 360, Len: 353
    Source port: 1083 (1083)
    Destination port: http (80)
    Sequence number: 423 (relative sequence number)
    Next sequence number: 776 (relative sequence number)
    Acknowledgement number: 360 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65176
    Checksum: 0x1b3d [incorrect, should be 0x1e0c]
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    8 0.139786 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=360 Ack=776 Win=49368 Len=0
    Frame 8 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x006e (110)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2ea1 [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 0
    Source port: http (80)
    Destination port: 1083 (1083)
    Sequence number: 360 (relative sequence number)
    Acknowledgement number: 776 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
    Window size: 49368
    Checksum: 0xdd7e [correct]
    No. Time Source Destination Protocol Info
    9 0.144850 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 404 Not Found (text/html)
    Frame 9 (464 bytes on wire, 464 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 450
    Identification: 0x006f (111)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2d06 [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 410
    Source port: http (80)
    Destination port: 1083 (1083)
    Sequence number: 360 (relative sequence number)
    Next sequence number: 770 (relative sequence number)
    Acknowledgement number: 776 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 49368
    Checksum: 0x7a71 [correct]
    Hypertext Transfer Protocol
    Line-based text data: text/html
    No. Time Source Destination Protocol Info
    10 0.269307 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=776 Ack=770 Win=64766 [TCP CHECKSUM INCORRECT] Len=0
    Frame 10 (54 bytes on wire, 54 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x02af (687)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xde5f [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 776, Ack: 770, Len: 0
    Source port: 1083 (1083)
    Destination port: http (80)
    Sequence number: 776 (relative sequence number)
    Acknowledgement number: 770 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
    Window size: 64766
    Checksum: 0x19dc [incorrect, should be 0x9fbe]

    lev wrote:This performance regression renders openvpn with a tun adapter unusable if client and server use kernel 3.14 .
    Thus I created a bug report: https://bugs.archlinux.org/task/40089
    i actually noticed it to be an "either-or" type of thing; my Windows clients were seeing the same thing coming off a 3.14 openvpn server.
    yeah, weird issue. like i noticed spurts of even-powers-of-2 sized packets
    Client connecting to 10.10.10.6, TCP port 5001
    TCP window size: 416 KByte
    [ 3] local 10.10.10.1 port 40643 connected with 10.10.10.6 port 5001
    [ ID] Interval Transfer Bandwidth
    [ 3] 0.0- 2.0 sec 512 KBytes 2.10 Mbits/sec
    [ 3] 2.0- 4.0 sec 0.00 Bytes 0.00 bits/sec
    [ 3] 4.0- 6.0 sec 0.00 Bytes 0.00 bits/sec
    [ 3] 6.0- 8.0 sec 0.00 Bytes 0.00 bits/sec
    [ 3] 8.0-10.0 sec 128 KBytes 524 Kbits/sec
    [ 3] 10.0-12.0 sec 128 KBytes 524 Kbits/sec
    [ 3] 12.0-14.0 sec 512 KBytes 2.10 Mbits/sec
    [ 3] 14.0-16.0 sec 128 KBytes 524 Kbits/sec
    [ 3] 16.0-18.0 sec 512 KBytes 2.10 Mbits/sec
    [ 3] 18.0-20.0 sec 128 KBytes 524 Kbits/sec
    [ 3] 20.0-22.0 sec 384 KBytes 1.57 Mbits/sec
    [ 3] 22.0-24.0 sec 256 KBytes 1.05 Mbits/sec
    [ 3] 24.0-26.0 sec 512 KBytes 2.10 Mbits/sec
    [ 3] 26.0-28.0 sec 384 KBytes 1.57 Mbits/sec
    [ 3] 28.0-30.0 sec 256 KBytes 1.05 Mbits/sec
    [ 3] 30.0-32.0 sec 128 KBytes 524 Kbits/sec
    [ 3] 32.0-34.0 sec 640 KBytes 2.62 Mbits/sec
    [ 3] 34.0-36.0 sec 384 KBytes 1.57 Mbits/sec
    [ 3] 36.0-38.0 sec 384 KBytes 1.57 Mbits/sec
    [ 3] 38.0-40.0 sec 384 KBytes 1.57 Mbits/sec
    [ 3] 40.0-42.0 sec 128 KBytes 524 Kbits/sec

  • Solaris Kernel and TCP/IP Tuning Parameters (Continued)

    This page describes some configuration optimizations for Solaris hosts running ATG Page Serving instances (application servers) that will increase server efficiency.
    Note that these changes are specific to Solaris systems running ATG application servers (+page serving+ instances). Do not use these on a web server or database server. Those systems require entirely different settings.
    h3. Solaris 10 Kernel
    Adjust /etc/system (parameters below) and reboot the system.
    set rlim_fd_cur=4096
    set rlim_fd_max=4096
    set tcp:tcp_conn_hash_size=32768
    set shmsys:shminfo_shmmax=4294967295
    set autoup=900
    set tune_t_fsflushr=1h4. Set limits on file descriptors
    {color:blue}set rlim_fd_max = 4096{color}
    {color:blue}set rlim_fd_cur = 4096{color}
    Raise the file-descriptor limits to a maximum of 4096. Note that this tuning option was not mentioned in the "Sun Performance And Tuning" book.
    [http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-32/index.html]
    h4. Increase the connection hash table size
    {color:blue}set tcp:tcp_conn_hash_size=8192{color}
    Increase the connection hash table size to make look-up's more efficient. The connection hash table size can be set only once, at boot time.
    [http://download.oracle.com/docs/cd/E19455-01/816-0607/chapter4-63/index.html]
    h4. Increase maximum shared memory segment size
    {color:blue}set shmsys:shminfo_shmmax=4294967295{color}
    Increase the maximum size of a system V shared memory segment that can be created from roughly 8MB to 4GB.
    This provides an adequate ceiling; it does not imply that shared memory segments of this size will be created.
    [http://download.oracle.com/docs/cd/E19683-01/816-7137/chapter2-74/index.html]
    h4. Increase memory allocated for dirty pages
    {color:blue}set autoup=900{color}
    Increase the amount of memory examined for dirty pages in each invocation and frequency of file system synchronizing operations.
    The value of autoup is also used to control whether a buffer is written out from the free list. Buffers marked with the B_DELWRI flag (which identifies file content pages that have changed) are written out whenever the buffer has been on the list for longer than autoup seconds. Increasing the value of autoup keeps the buffers in memory for a longer time.
    [http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-16/index.html]
    h4. Specify the time between fsflush invocations
    Specifies the number of seconds between fsflush invocations.
    {color:blue}set tune_t_fsflushr=1{color}
    [http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-105/index.html]
    Again, note that after adjusting any of the preceding kernel parameters you will need to reboot the Solaris server.
    h3. TCP
    ndd -set /dev/tcp tcp_time_wait_interval 60000
    ndd -set /dev/tcp tcp_conn_req_max_q 16384
    ndd -set /dev/tcp tcp_conn_req_max_q0 16384
    ndd -set /dev/tcp tcp_ip_abort_interval 60000
    ndd -set /dev/tcp tcp_keepalive_interval 7200000
    ndd -set /dev/tcp tcp_rexmit_interval_initial 4000
    ndd -set /dev/tcp tcp_rexmit_interval_max 10000
    ndd -set /dev/tcp tcp_rexmit_interval_min 3000
    ndd -set /dev/tcp tcp_smallest_anon_port 32768
    ndd -set /dev/tcp tcp_xmit_hiwat 131072
    ndd -set /dev/tcp tcp_recv_hiwat 131072
    ndd -set /dev/tcp tcp_naglim_def 1h4. Tuning the Time Wait Interval and TCP Connection Hash Table Size
    {color:blue}/usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000{color}
    The tcp_time_wait_interval is how long a connection stays in the TIME_WAIT state after it has been closed (default value 240000 ms or 4 minutes). With the default setting, this socket will remain for 4 minutes after you have closed the FTP connection. This is normal operating behavior. It is done to ensure that any slow packets on the network will arrive before the socket is completely shutdown. As a result, a future program that uses the same socket number won't get confused upon receipt of packets that were intended for the previous program.
    On a busy Web server a large backlog of connections waiting to close could build up and the kernel can become inefficient in locating an available TCP data structure. Therefore it is recommended to change this value to 60000 ms or 1 minute.
    h4. Tuning the maximum number of requests per IP address per port
    {color:blue}ndd -set /dev/tcp tcp_conn_req_max_q 16384{color}
    {color:blue}ndd -set /dev/tcp tcp_conn_req_max_q0 16384{color}
    The {color:blue}tcp_conn_req_max_q{color} and {color:blue}tcp_conn_req_max_q0{color} parameters are associated with the maximum number of requests that can be accepted per IP address per port. tcp_conn_req_max_q is the maximum number of incoming connections that can be accepted on a port. tcp_conn_req_max_q0 is the maximum number of “half-open” TCP connections that can exist for a port. The parameters are separated in order to allow the administrator to have a mechanism to block SYN segment denial of service attacks on Solaris.
    The default values are be too low for a non-trivial web server, messaging server or directory server installation or any server that expects more than 128 concurrent accepts or 4096 concurrent half-opens. Since the ATG application servers are behind a DMZ firewall, we needn't starve these values to ensure against DOS attack.
    h4. Tuning the total retransmission timeout value
    {color:blue}ndd -set /dev/tcp tcp_ip_abort_interval 60000{color}
    {color:blue}tcp_ip_abort_interval{color} specifies the default total retransmission timeout value for a TCP connection. For a given TCP connection, if TCP has been retransmitting for tcp_ip_abort_interval period of time and it has not received any acknowledgment from the other endpoint during this period, TCP closes this connection.
    h4. Tuning the Keep Alive interval value
    {color:blue}ndd -set /dev/tcp tcp_keepalive_interval 7200000{color}
    {color:blue}tcp_keepalive_interval{color} sets a probe interval that is first sent out after a TCP connection is idle on a system-wide basis.
    If SO_KEEPALIVE is enabled for a socket, the first keep-alive probe is sent out after a TCP connection is idle for two hours, the default value of the {color:blue}tcp_keepalive_interval{color} parameter. If the peer does not respond to the probe after eight minutes, the TCP connection is aborted.
    The {color:blue}tcp_rexmit_interval_*{color} values set the initial, minimum, and maximum retransmission timeout (RTO) values for a TCP connections, in milliseconds.
    h4. Tuning the TCP Window Size
    {color:blue}/usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 65535{color}
    {color:blue}/usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 65535{color}
    Setting these two parameters controls the transmit buffer and receive window. We are tuning the kernel to set each window to 65535 bytes. If you set it to 65536 bytes (64K bytes) or more with Solaris 2.6, you trigger the TCP window scale option (RFC1323).
    h4. Tuning TCP Slow Start
    {color:blue}/usr/sinb/ndd -set /dev/tcp tcp_slow_start_initial 4{color}
    tcp_slow_start_initial is the number of packets initially sent until acknowledgment, the congestion window limit.
    h4. Tuning the default bytes to buffer
    {color:blue}ndd -set /dev/tcp tcp_naglim_def 1{color}
    {color:blue}tcp_naglim_def{color} is the default number of bytes to buffer. Each connection has its own copy of this value, which is set to the minimum of the MSS for the connection and the default value. When the application sets the TCP_NODELAY socket option, it changes the connection's copy of this value to 1. The idea behind this algorithm is to reduce the number of small packets transmitted across the wire by introducing a short (100ms) delay for packets smaller than some minimum.
    Changing the value of tcp_naglim_def to 1 will have the same effect (on connections established after the change) as if each application set the TCP_NODELAY option.
    {note}
    The current value of any of the TCP parameters can be displayed with the command ndd get. So to retrieve the current setting of the {color:blue}tcp_naglim_def parameter{color}, simply execute the command:\\
    {color:blue}ndd -get /dev/tcp tcp_naglim_def{color}
    {note}
    h3. References
    Solaris Tunable Parameters Reference Manual
    [http://download.oracle.com/docs/cd/E19455-01/816-0607/index.html]
    WebLogic Server Performance and Tuning
    [http://download.oracle.com/docs/cd/E11035_01/wls100/perform/OSTuning.html]

    For example,
    Socket.setSoTimeout() sets SO_TIMEOUT option and I
    want to what TCP parameter this option corresponds in
    the underlying TCP connection.This doesn't correspond to anything in the connection, it is an attribute of the API.
    The same questions
    arises fro other options from SocketOptions class.setTcpNoDelay() controls the Nagle algorithm. set{Send,Receive}BufferSize() controls the local socket buffers.
    Most of this is quite adequately described in the javadoc actually.

  • Resolving a TCP connection "slowdown" problem

    SuSE 9.3, stock kernel
    Intel architecture
    Jrockit-R26.4.0-jdk1.5.0_06-linux-ia32
    I have a problem that appears to be localized in Jrockit (or
    localized in the application, which is localized in Jrockit), where a
    persistent and high-volume TCP connection slows down over the course
    of about an hour--and eventually, effectively halts.
    The TCP traffic is a stream of data, arriving at a near-constant rate
    of about 16K bytes per second, with the receiving end (with the JVM
    and app) strictly sending TCP ACKs in reply.
    Restarting the sending process, or shutting down and restarting the
    connection with the JVM / app, both restore the connection to full
    speed until, over the course of perhaps an hour (sometimes more,
    sometimes less) the same symptoms appear.
    The symptoms in network packet traces are that when the connection is
    first opened, the sender transmits packets at the full MTU of the
    Ethernet segment. Gradually, the number of full-MTU sized packets
    are replaced with packets much smaller packets, until most packets
    range from 1 to 4 bytes with the occasional 3xx-4xx byte packet and
    the odd offlier of a full-MTU packet size.
    Supporting symptoms of interest:
    1) The TCP window does not shrink
    2) The CPU on the JVM/app side tops out at around 20%, even with
    mySQL running on the machine
    3) The interval between successive ACKs transmitted from the JVM/app
    size generally narrows over the course of the connection
    4) TCP send queue on the sender becomes saturated (pegged at 90+ K)
    5) TCP receive queue on the JVM/app side is almost always 0, and when
    it is not zero is bursts up to a low number (<50) and then almost
    immediately returns to 0
    6) The app does not appear to present any general symptoms of
    slowness; the rate of writes to the database does not appear to slow.
    The writes are threaded and multiplexed
    [4] strongly implies that the slowness is caused by the JVM/app side,
    since if the sender app was slowing down for some reason its TCP send
    queue would not be saturated.
    I can copiously document everything stated, and additionally provide
    much additional detail.
    Any guidance on how to suss out role Jrockit or the app are playing
    in this little drama would be very deeply appreciated.

    Asked around and it seems unlikely that this is a JVM issue. We have never heard of this behavior before, and the network layer in the JVM doesn't do anything with MTU iirc with the possible exception of manual changes to socket options. It seems more likely that this is caused by the IP stack, the NIC device driver or something in the network configuration. Try making some changes here and see what happens. For instance:
    1) Run client and server on the same machine, communicating through loopback
    2) Try another Linux distro (CentOS 4.3, for instance)
    3) Try a different NIC and/or a different device driver
    In your Java code, check that you are closing all Socket objects properly. Leaving them to be closed by a finalizer can delay closing sockets resulting in a native resource leak. I don't see how that would cause the issue you describe, but you never know...

  • Tuning Oracle*Net over TCP/IP

    Hi,
    Anyone have any info on how Oracle uses the SDU parameter in tnsnames.ora and listener.ora. Is the SDU in any way related to the maximum TCP data that the TCP socket between the client and server can have outstanding?
    Does any one have experience with making oracle use the full tcp window (eg window > 32KB) between the Server and the client such as sqlplus?
    Thanks,
    Satya

    Here is a useful article:
    http://www.akadia.com/services/ora_net_tuning.html
    SCJP, SCJD, SCEA, SCWCD, SCBCD
    CISSP, PMP, PHR
    OCPDBA 8i/9i
    http://www.certgear.com

Maybe you are looking for

  • How do you check Memory Speed on ICD

    Hi everyone I am new to the forums and I am also a soon to be first time mac owner(Receiving my 20" ICD this week) . I am buying the imac with an extra 1gig DIMM installed, non-apple memory. Now the reseller assures me that the 3rd party memory that

  • T61P Audio stuttering at bootup in Windows Vista Business

    I did some googling on this and saw that mine isn't the only Lenovo with this issue, and it's not a big deal, but I would like to fix it so the bootup is silent until "music" (especially since I'm a musician with keen hearing and want my audio right)

  • Form Label Text-Align Center

    I am having troubles aligning the label of my form to center. When the page loads, it looks like it wants to be center aligned, but then aligns to the left. I can't tell which CSS is making it do this. Would you be able to help me narrow it down? lin

  • I want a number for iMessage

    I don't want to use my Apple ID I want to use a number

  • EBS OATM Migration

    Has anyone migrated a 300gb or larger database to OATM? Are there any known performance issues after the database has been migrated to OATM?