Was ist NAFC ?

Das "Network adapter Feedback Control" richtet den eMule-Upload nach dem am Netzwerkadapter gemessenem Gesamtupload aller Anwendungen aus. Das in eMule eingestellte Uploadlimit berücksichtigt somit nicht nur eMule-Daten, sondern alle Upload-Packete aller Anwendungen (Webbrowser, Onlinegames, FTP-Upload usw.).

Ist beispielsweise der Upload auf 15 kbs eingestellt und eine Internettelefonie verbraucht 5 kbs Upload, so sendet eMule nur noch 10 kbs an Daten. Durch dieses Verfahren wird eine geringere Pingzahl gewährleistet und die Uploadkapazität am optimalsten ausgenutzt. Bei Verwendung von NAFC lässt sich das Uploadlimit ganz dicht unterhalb der Uploadkapazität einstellen.
Um Missbrauch des Features vorzubeugen, schaut eMule nach, ob die gemessenen Daten eMule-Daten sind oder Daten anderer Anwendungen. Sind die gesendeten eMule-Daten (Nutzdaten + Overhead) kleiner als 11 kbs, so schaltet sich dynamisch ein Downloadlimit ein.
 

Hier mal die offizielle Erklärung zu NAFC (Maella Mod), die den gleichen Sinn hat wie SUC oder zz USS:

Introduction

All applications that need to regulate their upload bandwidth face the same problems. When you ask the operating system (OS) to send data to a remote client, three different things could happen:
- The sending could be proceed immediately
- The sending could be delayed by the OS (e.g. remote client not ready, limit of the capacity of the network already reached)
- The sending could be never proceed by the OS (e.g. connection with the remote client is lost)

Another problem is that a part of the traffic on the network is generated by the protocol itself. So typically when data are received from a remote client, the OS must send some acknowledge (ACK) packets to the remote side to validate the transfer. These ACK will increase the overall traffic as well. The protocol creates an overhead that an application can not fully control.

And finally, others applications can generate traffic for their own purposes (e.g. ftp, browser).

In summary: when an application attempts to regulate its traffic, it knows what it's trying to send, but it doesn't know exactly when it is sent and what it is sent.

Ideal Solution

In the case of eMule, the ideal solution would be to know in real time the current level of the traffic though the modem (e.g. K56, ADSL, etc..). So if an application was award of it, it would be piece of cake to regulate the bandwidth. Keep in mind that the goal is to use all the time 100% of the capacity of the modem. Nothing more, nothing less!

Unfortunately, there is no easy way to retrieve this information from the modem.

Current solutions

There are different approach to solve the above problem. Here it a list with some of them:

1. Under use the bandwidth to insure having enough rooms for the protocol overhead (e.g. the official eMule).

Disadvantage:
-all bandwidth is not used

2. Try to send periodically packets (ping) with the purpose of measuring the reaction time of the modem. So if the reaction time gets too high, it could indicate a beginning of saturation of the modem (e.g. ZZ UploadSpeedSense).

Disadvantage:
-add overhead to the traffic for the measure
-limited reaction time > 1s
-medium accuracy

3. Try to measure the reaction time of the remote clients. (e.g. SUC).

Advantage:
-no overhead

Disadvantage:
-limited reaction time >1s
-medium accuracy
-depends on the capacity of both the local and remote modems.

4. Measure the traffic at the network adapter level (Ethernet card) and not at the modem level. If all the traffic is only exchanged with the modem, then the network adapter will have a 1 to 1 image the modem's traffic => NAFC

Advantage:
-no overhead
-reaction time very fast <100 ms
-very accurate
Disadvantage:
-not available with all OS (e.g. win95)
-might require administrator right (could be change somewhere in settings)
-measure all the traffic sent or received by the local computer on the network (e.g. traffic with the modem + traffic with other computers on the local network)

5. Use the Layered Service Provider of windows....

Summary

The NAFC is certainly the best solution, but only if the network adapter is only used to exchange data with the modem.

Den wichtigsten Punkt nochmal zusammengefaßt:
NAFC funktioniert nicht wenn man seinen Rechner in einem Netzwerk betreibt, da NAFC den gesamten Traffic (Internet + Traffic zu anderen Computern) berücksichtigt