[Gelöst] Regeln für Multicast und IGMP Relay
-
Schön wenn es funktioniert!
-
@u1: Was ich mich von WDS Präsentationen noch erinnern kann ist, dass beim Streaming im Multicast Modus die Clients das Image nicht alle gleichzeitig bekommen, sondern jeder Client sich per Multicast in den Stream einklinkt und der Server den Kram eben so lange endlos wiederholt (Image streamt immer und immer wieder), bis es jeder quittiert hat. Daher ist wohl eher der Zeitunterschied in deinem Test zu resultieren, dass der zweite und ggf. dritte Client sich eben nicht exakt zeitgleich mit Client 1 in den Stream einhängen können und damit warten müssen, bis der Stream durch ist (3-4min) und dann bekommen sie ihr Abbild im zweiten oder dümmsten Fall dritten durchrutsch.
Das mit den Paketen kann ich aber nicht ganz glauben ;) denn die MTU von 1500 bleibt auf Layer 2 und gilt damit für jedes Protokoll, egal ob TCP oder UDP. Package Size bleibt Package Size und solange du keine Jumbo Frames von 9000 auf deinem Switch konfiguriert hast, bleibt ein TCP oder UDP Package maximal 1500 Byte groß :)
-
Ah, interessant. Der Mechanismus erlaubt ungefähr zeitgleiche Installationen für mehrere Clients in annähernd konstanter Zeit – also unabhängig von der Zahl der Clients. Das wird bei einer Messung mit zwei oder drei Clients wahrscheinlich nicht sichtbar, bei 10 Clients dürfte das aber nicht viel länger dauern als mit drei. Und bei 100 Clients auch nicht, aber es spart dann erheblich Netzwerklast ein.
-
… dass beim Streaming im Multicast Modus die Clients das Image nicht alle gleichzeitig bekommen...
Das wäre die Standardeinstellung einer Multicastübertragung. Die lässt sich aber ändern:
Das mit den Paketen kann ich aber nicht ganz glauben ;)
Ursache scheint TCP segmentation offload zu sein. Wireshark zeigt mir TCP-Pakete mit 62.384 Byte Länge an und kennzeichnet sie als TCP segment of a reassembled PDU. Die Länge des IP-Datagramms beträgt 62.820 Byte, allerdings vermerkt Wireshark dazu: reported as 0, prsumed to because of "TCP segmantation offload" (TSO). Die Framelänge beträgt 62.834 Byte.
-
Der Mechanismus erlaubt ungefähr zeitgleiche Installationen für mehrere Clients in annähernd konstanter Zeit – also unabhängig von der Zahl der Clients.
Ich schätze (das in einem Test zu verifizieren ist mir zu aufwändig), dass sich der Geschwindigkeitsvorteil erst ab etwa 20 bis 30 Clients bemerkbar macht. Darunter dürfte es eher ein Geschwindigkeitsnachteil sein.
-
Das würde mich wundern wenn tcp schneller wäre.
Wie schon geschrieben wurde , kann ein Paket unfragmentiert nicht größer werden als 1500 Byte (vergessen wir mal Jumbo Franes)Zudem hat tcp einiges an Protokoll Overhread durch die ACK Pakete
-
Ich habe mal 99 Pakete aus Wireshark exportiert, die den SMB-Verkehr zwischen dem WDS-Server (hier 192.168.2.10) und zwei Clients (192.168.0.100 und 192.168.0.101) enthalten. Insgesamt habe ich etwa eine Minute aufgezeichnet, das sind etwas mehr als 1 GB, deutlich zu groß für diese Forum.
Vielleicht kann ja ein Experte Aufklärung liefern.
-
Das sieht interessant aus. Ich würde mal im Hyper-V in die Einstellungen der Netzwerk-Adapter schauen.
-
Hab ich geschaut. Und nun?
<glaskugel an="">Ich vermute, du möchtest die Einstellungen der Netzwerkadapter wissen.
<glaskugel aus="">```PS C:\WINDOWS\system32> Get-VMNetworkAdapter -VM $VM | Format-List -Property *
VMCheckpointId : 00000000-0000-0000-0000-000000000000
VMCheckpointName :
ClusterMonitored : True
MacAddress : 00155D09C80B
DynamicMacAddressEnabled : True
AllowPacketDirect : False
IsLegacy : False
IsSynthetic : True
IPAddresses : {}
DeviceNaming : Off
IovWeight : 0
IovQueuePairsRequested : 1
IovInterruptModeration : Default
PacketDirectNumProcs : 0
PacketDirectModerationCount : 64
PacketDirectModerationInterval : 1000000
IovQueuePairsAssigned : 0
IovUsage : 0
VirtualFunction :
MandatoryFeatureId : {}
MandatoryFeatureName : {}
PoolName :
Connected : True
SwitchName : Büro
AdapterId :
TestReplicaPoolName :
TestReplicaSwitchName :
StatusDescription :
Status :
IsManagementOs : False
IsExternalAdapter : False
Id : Microsoft:6F06FC55-3E67-4CF7-A0F4-958C2A027645\D876E580-C712-4518-8E2B-63258D012432
SwitchId : a9982010-820a-4b19-9025-a068b71f2d21
AclList : {}
ExtendedAclList : {}
IsolationSetting : VMNetworkAdapterIsolationSetting
RoutingDomainList : {}
VlanSetting : VMNetworkAdapterVlanSetting
BandwidthSetting :
CurrentIsolationMode : Vlan
MacAddressSpoofing : Off
DhcpGuard : Off
RouterGuard : Off
PortMirroringMode : None
IeeePriorityTag : Off
VirtualSubnetId : 0
DynamicIPAddressLimit : 0
StormLimit : 0
AllowTeaming : Off
FixSpeed10G : Off
VMQWeight : 100
IPsecOffloadMaxSA : 512
VrssEnabled : True
VrssEnabledRequested : True
VmmqEnabled : False
VmmqEnabledRequested : False
VmmqQueuePairs : 0
VmmqQueuePairsRequested : 16
VmqUsage : 0
IPsecOffloadSAUsage : 0
VFDataPathActive : False
VMQueue :
BandwidthPercentage : 0
IsTemplate : False
Name : Netzwerkkarte
VMId : 6f06fc55-3e67-4cf7-a0f4-958c2a027645
VMName : xxx
VMSnapshotId : 00000000-0000-0000-0000-000000000000
VMSnapshotName :
CimSession : CimSession: .
ComputerName : xxx
IsDeleted : FalseDas sind die Einstellungen des WDS-Server und der Clients. Es ist also alles auf den Standardeinstellungen. Die VM "pfSense" hat sogar Legacy-Adapter. Falls mich meine Glaskugel getäuscht hat präzisiere bitte deine Anfrage.</glaskugel></glaskugel> -
Offen gestanden kann ich auch nur raten. In Deinem Trace sind tatsächlich sehr große Frames. Das geht nur, wenn alle Komponenten mitmachen, also insb. alle (virtuellen) Netzwerkadapter. Ich kenne mich mit Hyper-V aber auch nicht aus.
Von so großen Frames habe ich auch noch nie gehört, aber TCP erlaubt m.W. ein theoretisches Maximum von 64K.
