Keresés

Új hozzászólás Aktív témák

  • crok

    nagyúr

    válasz MasterMark #7521 üzenetére

    Parancsolj, TCP offload engine leírások..
    egy háklis ügyfelemnek szedtem össze anno egy emailben..
    Egyébként a bufferezés meg gyártófüggő, az hogy auto vagy nem meg (Windows-on) driver+verzió függő, mert pl. 2k3-ban by default auto még ha nincs is támogatva és persze force-olja a NIC-re, aztán DMA storm is lehet belőle, odavissza pattogó kérésekkel a CPU meg a NIC közt.. csomagonként.. hogy ezt most kiszervezném de a NIC nem támogatja, meg ezt is kiszervezném, de a NIC nem támogatja, et cetera.. és így lesz az "érthetetlen lag"..

    TCP Chimney, TCPIP Offload Engine (TOE) or TCP Segmentation Offload (TSO)

    http://support.microsoft.com/kb/951037
    http://windows.microsoft.com/en-us/windows-vista/what-is-tcp-chimney-offload
    http://en.wikipedia.org/wiki/TCP_offload_engine
    https://msdn.microsoft.com/en-us/library/windows/hardware/ff570929(v=vs.85).aspx
    https://docs.microsoft.com/en-us/windows-hardware/drivers/network/tcp-chimney-architecture
    https://blogs.technet.microsoft.com/onthewire/2014/01/21/tcp-offloadingchimney-rsswhat-is-it-and-should-i-disable-it/

    TCP Chimney Offload is a networking technology that allows the work associated with moving data across a network to be offloaded from the host computer's CPU to the network adapter. This helps improve the processing of network data on your computer or server without the need for additional programs or any loss to manageability or security. Programs that are currently bound by network processing overhead will generally scale better when used with TCP Chimney Offload.

    Known Issues:
    o Limitations of hardware — because connections are buffered and processed on the TOE chip, resource limitations happen more often then they would if processed by the ample CPU and memory resources that are available to the operating system. This limitation of resources on the TOE chip can cause communication issues.
    o Complexity — issues such as memory used by open connections are not available with TOE. TOE also requires very large changes to a networking stack in order to be supported properly, and even when that is done, features like Quality of Service and packet filtering typically do not work.
    o Proprietary — TOE is implemented differently by each hardware vendor. This means more code must be rewritten to deal with the various TOE implementations, at a cost of the aforementioned complexity and, possibly, security. Furthermore, TOE firmware cannot be easily modified since it is closed-source.
    o Performance — Each TOE NIC has a limited lifetime of usefulness, because system hardware rapidly catches up to TOE performance levels, and eventually exceeds TOE performance levels. TOE does not increase bandwidth on the network. In simple terms, TOE removes the responsibility of the protocol stack from the Server’s CPU allowing the server CPU to process information faster. As hardware performance increases, processes can complete their task prior to TOEs acknowledgment of the receipt of transmission; thus causing communication issues.

    Error
    o A transport-level error has occurred when sending the request to the server (provider: TCP Provider, error 0 - An existing connection was forcibly closed by the remote host.)
    Cause
    o This issue can occur when either TCP Chimney Offload, TCP/IP Offload Engine (TOE) or TCP Segmentation Offload (TSO) are enabled.
    o TCP Chimney, TCPIP Offload Engine (TOE) and TCP Segmentation Offload (TSO) off loads the TCP protocol stack to a Network Interface Card (NIC).
    a TCP Chimney is Microsoft's software enhancement.
    b TOE is the NIC manufacturer's hardware enhancement.
    c TSO is the equivalent to TOE for some virtual environment configurations.
    The TCP Chimney Offload feature is enabled by default in the Windows Server 2003 Scalable Networking Pack. This update is included in Windows Server 2003 Service Pack 2 and can also be installed on a server running Windows 2003 Service Pack 1.

    Solution: implement the following actions and the below Workaround to better ensure resolution of the issue:
    o Obtain the latest basic input/output system (BIOS) update for the server
    o Obtain the latest firmware update for the network adapter
    o Obtain the latest driver update for the network adapter
    Workaround and solutions, like disable TCP Chimney Offload feature, et cetera:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
    o Right-click EnableTCPChimney, and then click Modify.
    In the Value data box, type 0, and then click OK.
    o Right-click EnableRSS, and then click Modify.
    In the Value data box, type 0, and then click OK.
    o Right-click EnableTCPA, and then click Modify.
    In the Value data box, type 0, and then click OK.
    o Exit Registry Editor, and then restart the computer.

    http://www.symantec.com/business/support/index?page=content&id=TECH197934
    http://support.microsoft.com/kb/948496/en-us
    http://knowledgebase.progress.com/articles/Article/P163165
    http://blogs.technet.com/b/onthewire/archive/2014/01/21/tcp-offloading-chimney-amp-rss-what-is-it-and-should-i-disable-it.aspx

    Slow file copy or slow file transfer with various Windows versions 2k8, 2k8R2, 2k3
    http://winntfs.com/2011/10/07/slow-file-copy-or-slow-file-transfer-with-various-windows-versions-2k8-2k8r2-2k3/
    Symptom: File copy or File transfer speed is slow, either to a local drive or a network drive, especially so when a Windows Server 2008 or newer Windows file server is involved.
    Possible Solutions in no particular Order
    o Make sure both IPv6 and IPv4 are running on 2008 R2, even if the 2008 R2 server is the lone IPv6 device on the network! There may be alternate solutions but this solution has been reported to work
    o Tune TCP on client – set autotuning to off "netsh interface tcp set global autotuninglevel=disabled"
    o Tune TCP on client and server – turn off receive side scaling "netsh interface tcp set global rss=disabled"
    o Tune TCP disable large send offload
    o Tune TCP disable large receive offload
    o Tune TCP – disable offload

    Client side:
    ncpa.cpl - network connections
    1. From the Run command: ncpa.cpl (or go via Control panel to Network connections)
    2. Right click on 'local area connection' > properties
    3. Click 'configure' to open new dialog box
    4. In 'Advanced' tab: select TCP checksum Offload (IPv6) & select 'Disabled' from drop-down menu.

    File copying from down-level systems to Windows Vista or Windows Server 2008 is significantly slower if Intel I/OAT (Intel I/O Acceleration Technology) is enabled on the computer.) is enabled
    http://support.microsoft.com/kb/968991

    http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574

    "magic fix" for so many problems involving network file transfers on Windows 7/2008?
    http://serverfault.com/questions/301429/tcp-offloading-netdma-magic-commands
    netsh interface tcp set global autotuning=disabled
    netsh interface tcp set global chimney=disabled
    netsh interface tcp set global rss=disabled

    http://ccie-or-null.net/2014/11/25/wireshark-tid-bit-packets-larger-than-the-mtu-size-why-how/
    http://sandilands.info/sgordon/segmentation-offloading-with-wireshark-and-ethtool

    A VPN-es kérdésed se tipikusan hálózatos.. természetesen fel lehet kapcsolódni olyan routerrel PPTP-n segítségéven a szerveredhez ami támogatja de a szervert meg a routert is jól kell beállítani, nem csak klikkklikkfiniss' mert általában fontos dolgok maradnak ki, mint a LAN megadása, a PPTP remote beállításainak megadása.. nem úgy megy ez hogy user+pass és akkor kapcsolódtam.. igen, kapcsolódtál, és hogyan fogja tudni a szerver mi van a router mögött? Honnan fogja tudni a router mi mehet a PPTP-ben és mi a "sima internet"? Semmilyen beállítás vagy támpont nincs a kérdésedben, se debug, se az égvilágon semmi azon kívül, hogy a log szerint PPTP-n próbálsz csatlakozni valamivel valamihez és kaptál egy hibakódot hogy nem ment.. még az se derül ki hogy a PPTP szervert DNS-el kellett-e feloldani IP-vé vagy eleve IP volt megadva (mert ha DNS és elírtad a szerver nevét és azért nem megy.. vagy a szerver is egy NAT-oló router mögött van-e, port forwarding megvan-e, port triggering be van-e állítva, tűzfal nyitva van-e a kapcsolatnak.. tud-e az a router PPTP pass-through-t? Mert ugye a PPTP nem csak TCP 1723 (a tunnel felépítésére) hanem GRE forgalom (maga a tunnel, az adat, ami egyébként nem GRE hanem eGRE) is, ami se nem TCP se nem UDP!) Érzed azért hogy ez így meglehetősen *kevés* információ.. Erre csak max. amolyan Gyurcsókos "küldömazenergiátérzedelmárral' tudok válaszolni.. én jegyben ilyet leírást kapok visszadobom.. értem hogy fáj ha megnyomod az ujjaddal, de hol nyomod meg és az ujjad fáj ha megnyomod vagy ott fáj ahol megnyomtad? Érted hogy hogy mondom..

    ..meg úgy gondolom PPTP-t használni 2017-ben balgaság. A pucér PPTP-nél kb. bármi jobb. Akkor már inkább a két router közt majdnem bármilyen IPSec aztán kapcsolódhatsz a szerverhez..

    Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..

  • crok

    nagyúr

    válasz MasterMark #7521 üzenetére

    @MasterMark: Nem volt elég kielégítő a válaszom?

    Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..

Új hozzászólás Aktív témák