I was a little worried if I played with it I might go into a spiral of
BSOD doom.
But it didn’t.
Seems to work fine, but not much difference. Setting the value to
anything other than 0 (need to verify 0) seems to allow interrupts to
use core 3 as well as core 1. It’s just a single hex core with HT, so a
lot of the NUMA stuff / multiprocessor stuff doesn’t apply.
But it’s certainly behaving differently now, and I’m not really pegging
core 0 any more. It definitely seems to prefer it, but seems more
willing to offload work to core 3 when it’s getting busy, and overall
tps has gone up.
Maybe time to buy a real network card and plug it in for testing.
Thanks
Adrien
------ Original Message ------
From: “Tim Roberts” To: “Windows System Software Devs Interest List” Sent: 9/05/2017 1:43:42 PM Subject: Re: [ntdev] Windows networking bottleneck - all socket notifications coming from 1 thread inside winsock?
>Adrien de Croy wrote: >> >> I looked in the registry under the Enum\PCI key for the device, and >> there are keys like “interrupt management” and “affinity policy”… I >> wonder if a bit of playing with some of those attributes may help. > >It is possible that dinking with the “affinity policy” might force the >system to spread the interrupts to other processors. > >HOWEVER, the authors of the driver would not have forced an affinity >policy without a good reason. To be more specific, it may be that all >of their interrupts are forced to CPU 0 because their driver cannot >handle multiple simultaneous interrupts in multiple processors. > >– >Tim Roberts, xxxxx@probo.com >Providenza & Boekelheide, Inc. > > >— >NTDEV is sponsored by OSR > >Visit the list online at: >http: > >MONTHLY seminars on crash dump analysis, WDF, Windows internals and >software drivers! >Details at http: > >To unsubscribe, visit the List Server section of OSR Online at >http:</http:></http:></http:>
------ Original Message ------
From: “Adrien de Croy” To: “Windows System Software Devs Interest List” Sent: 9/05/2017 4:42:20 PM Subject: Re: [ntdev] Windows networking bottleneck - all socket notifications coming from 1 thread inside winsock?
>understood > >I was a little worried if I played with it I might go into a spiral of >BSOD doom. > >But it didn’t. > >Seems to work fine, but not much difference. Setting the value to >anything other than 0 (need to verify 0) seems to allow interrupts to >use core 3 as well as core 1. It’s just a single hex core with HT, so a >lot of the NUMA stuff / multiprocessor stuff doesn’t apply. > >But it’s certainly behaving differently now, and I’m not really pegging >core 0 any more. It definitely seems to prefer it, but seems more >willing to offload work to core 3 when it’s getting busy, and overall >tps has gone up. > >Maybe time to buy a real network card and plug it in for testing. > >Thanks > >Adrien > >------ Original Message ------ >From: “Tim Roberts” >To: “Windows System Software Devs Interest List” >Sent: 9/05/2017 1:43:42 PM >Subject: Re: [ntdev] Windows networking bottleneck - all socket >notifications coming from 1 thread inside winsock? > >>Adrien de Croy wrote: >>> >>> I looked in the registry under the Enum\PCI key for the device, and >>> there are keys like “interrupt management” and “affinity policy”… >>>I >>> wonder if a bit of playing with some of those attributes may help. >> >>It is possible that dinking with the “affinity policy” might force the >>system to spread the interrupts to other processors. >> >>HOWEVER, the authors of the driver would not have forced an affinity >>policy without a good reason. To be more specific, it may be that all >>of their interrupts are forced to CPU 0 because their driver cannot >>handle multiple simultaneous interrupts in multiple processors. >> >>– >>Tim Roberts, xxxxx@probo.com >>Providenza & Boekelheide, Inc. >> >> >>— >>NTDEV is sponsored by OSR >> >>Visit the list online at: >>http: >> >>MONTHLY seminars on crash dump analysis, WDF, Windows internals and >>software drivers! >>Details at http: >> >>To unsubscribe, visit the List Server section of OSR Online at >>http: > > >— >NTDEV is sponsored by OSR > >Visit the list online at: >http: > >MONTHLY seminars on crash dump analysis, WDF, Windows internals and >software drivers! >Details at http: > >To unsubscribe, visit the List Server section of OSR Online at >http:</http:></http:></http:></http:></http:></http:>
A quick look at the Intel documentation for this chip suggests that it might not support RSS fully. Try testing with a known IP performance tool and see what results you get
From: Adrien de Croymailto:xxxxx Sent: May 9, 2017 12:45 AM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: Re: [ntdev] Windows networking bottleneck - all socket notifications coming from 1 thread inside winsock?
sorry that should read core 0 and 2
Adrien
------ Original Message ------ From: “Adrien de Croy” To: “Windows System Software Devs Interest List” Sent: 9/05/2017 4:42:20 PM Subject: Re: [ntdev] Windows networking bottleneck - all socket notifications coming from 1 thread inside winsock?
>understood > >I was a little worried if I played with it I might go into a spiral of >BSOD doom. > >But it didn’t. > >Seems to work fine, but not much difference. Setting the value to >anything other than 0 (need to verify 0) seems to allow interrupts to >use core 3 as well as core 1. It’s just a single hex core with HT, so a >lot of the NUMA stuff / multiprocessor stuff doesn’t apply. > >But it’s certainly behaving differently now, and I’m not really pegging >core 0 any more. It definitely seems to prefer it, but seems more >willing to offload work to core 3 when it’s getting busy, and overall >tps has gone up. > >Maybe time to buy a real network card and plug it in for testing. > >Thanks > >Adrien > >------ Original Message ------ >From: “Tim Roberts” >To: “Windows System Software Devs Interest List” >Sent: 9/05/2017 1:43:42 PM >Subject: Re: [ntdev] Windows networking bottleneck - all socket >notifications coming from 1 thread inside winsock? > >>Adrien de Croy wrote: >>> >>> I looked in the registry under the Enum\PCI key for the device, and >>> there are keys like “interrupt management” and “affinity policy”… >>>I >>> wonder if a bit of playing with some of those attributes may help. >> >>It is possible that dinking with the “affinity policy” might force the >>system to spread the interrupts to other processors. >> >>HOWEVER, the authors of the driver would not have forced an affinity >>policy without a good reason. To be more specific, it may be that all >>of their interrupts are forced to CPU 0 because their driver cannot >>handle multiple simultaneous interrupts in multiple processors. >> >>– >>Tim Roberts, xxxxx@probo.com >>Providenza & Boekelheide, Inc. >> >> >>— >>NTDEV is sponsored by OSR >> >>Visit the list online at: >>http: >> >>MONTHLY seminars on crash dump analysis, WDF, Windows internals and >>software drivers! >>Details at http: >> >>To unsubscribe, visit the List Server section of OSR Online at >>http: > > >— >NTDEV is sponsored by OSR > >Visit the list online at: >http: > >MONTHLY seminars on crash dump analysis, WDF, Windows internals and >software drivers! >Details at http: > >To unsubscribe, visit the List Server section of OSR Online at >http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>
yeah good call, might try with some other network hardware so different
drivers.
Adrien
------ Original Message ------
From: “Marion Bond” To: “Windows System Software Devs Interest List” Sent: 10/05/2017 10:24:50 AM Subject: RE: [ntdev] Windows networking bottleneck - all socket notifications coming from 1 thread inside winsock?
>A quick look at the Intel documentation for this chip suggests that it >might not support RSS fully. Try testing with a known IP performance >tool and see what results you get > > > >Sent from Mail https: for >Windows 10 > > > >From: Adrien de Croy mailto:xxxxx >Sent: May 9, 2017 12:45 AM >To: Windows System Software Devs Interest List >mailto:xxxxx >Subject: Re: [ntdev] Windows networking bottleneck - all socket >notifications coming from 1 thread inside winsock? > > > > >sorry that should read core 0 and 2 > >Adrien > > >------ Original Message ------ >From: “Adrien de Croy” >To: “Windows System Software Devs Interest List” >Sent: 9/05/2017 4:42:20 PM >Subject: Re: [ntdev] Windows networking bottleneck - all socket >notifications coming from 1 thread inside winsock? > > >understood > > > >I was a little worried if I played with it I might go into a spiral of > >BSOD doom. > > > >But it didn’t. > > > >Seems to work fine, but not much difference. Setting the value to > >anything other than 0 (need to verify 0) seems to allow interrupts to > >use core 3 as well as core 1. It’s just a single hex core with HT, so >a > >lot of the NUMA stuff / multiprocessor stuff doesn’t apply. > > > >But it’s certainly behaving differently now, and I’m not really >pegging > >core 0 any more. It definitely seems to prefer it, but seems more > >willing to offload work to core 3 when it’s getting busy, and overall > >tps has gone up. > > > >Maybe time to buy a real network card and plug it in for testing. > > > >Thanks > > > >Adrien > > > >------ Original Message ------ > >From: “Tim Roberts” > >To: “Windows System Software Devs Interest List” > >Sent: 9/05/2017 1:43:42 PM > >Subject: Re: [ntdev] Windows networking bottleneck - all socket > >notifications coming from 1 thread inside winsock? > > > >>Adrien de Croy wrote: > >>> > >>> I looked in the registry under the Enum\PCI key for the device, >and > >>> there are keys like “interrupt management” and “affinity policy”… > >>>I > >>> wonder if a bit of playing with some of those attributes may help. > >> > >>It is possible that dinking with the “affinity policy” might force >the > >>system to spread the interrupts to other processors. > >> > >>HOWEVER, the authors of the driver would not have forced an affinity > >>policy without a good reason. To be more specific, it may be that >all > >>of their interrupts are forced to CPU 0 because their driver cannot > >>handle multiple simultaneous interrupts in multiple processors. > >> > >>– > >>Tim Roberts, xxxxx@probo.com > >>Providenza & Boekelheide, Inc. > >> > >> > >>— > >>NTDEV is sponsored by OSR > >> > >>Visit the list online at: > >>http: > >> > >>MONTHLY seminars on crash dump analysis, WDF, Windows internals and > >>software drivers! > >>Details at http: > >> > >>To unsubscribe, visit the List Server section of OSR Online at > >>http: > > > > > >— > >NTDEV is sponsored by OSR > > > >Visit the list online at: > >http: > > > >MONTHLY seminars on crash dump analysis, WDF, Windows internals and > >software drivers! > >Details at http: > > > >To unsubscribe, visit the List Server section of OSR Online at > >http: > > >— >NTDEV is sponsored by OSR > >Visit the list online at: >http: > >MONTHLY seminars on crash dump analysis, WDF, Windows internals and >software drivers! >Details at http: > >To unsubscribe, visit the List Server section of OSR Online at >http: > > > > >— >NTDEV is sponsored by OSR > >Visit the list online at: >http: > >MONTHLY seminars on crash dump analysis, WDF, Windows internals and >software drivers! >Details at http: > >To unsubscribe, visit the List Server section of OSR Online at >http:</http:></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>