- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
AMT is taking more time to respond when host is in power off condition(tried enumeration calls with both soap and ws-man).
Power policy for AMT is : Desktop: ON in S0, ME Wake in S3, S4-5
Is this normal behaviour?
Can anyone explain about this
Thanks,
Mani
AMT is taking more time to respond when host is in power off condition(tried enumeration calls with both soap and ws-man).
Power policy for AMT is : Desktop: ON in S0, ME Wake in S3, S4-5
Is this normal behaviour?
Can anyone explain about this
Thanks,
Mani
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Let me go through what I believe are your three four questions currently
1. Will the responses be slower when the system is powered off?
Yes. Gael mentioned the ME powering off (or AMT being powered only in the S0 state), but even assuming the ME is powered, the system will respond slower in an Sx state. How much slower is AMT generation dependent, for instance the platform that is about to be released (AMT 7.0) is significantly faster in Sx, but it will be somewhat slower than when the system is in S0. This is dueto a variety of factors,but mainly that there are moreresourcespowered and available in S0.
2. Why am I getting some non-responses from AMTon anenumerate?
Given how you described performing theenumerate (a loop of 10 requests), it's possible that you are encountering AMT enumeration context limit.In AMT 6, thereis a limit of 3 active enumeration contexts. One possibility given the number of requests and how fast you are performing them, there's a possibility that the context's aren't freeing up before a new request comes in, meaning you would get an error back.
3. Why is ping not always responding?
This is not as clear cut as the previous answer, but one possibility is that the behavior has a similar cause.Ifthe ping is operating at the same time as the enumerations, there's a possibility that the ME is processing other requests and isn't responding before the ping considers the request timed out. I'm not sure what you are using for ping, or howquicklyit assumes a timeout, but that is a possibility.
4.Why is AMT not responding after I unplug the system and plug it back in?
When you unplug the system, it's losing it's DHCP address. I think this could be specific to the platform (given the behavior Rick saw), but there's a possibility that the system isn't requesting a new IP address until the system is powered on again. I see the same behavior you on my system when I pull the power and plug it back in.
For questions 2 and 3, one of my questions to you would be if you see the same behavior when the system is powered on (in an S0 state). If you don't, then likely it is related to AMT responding slower in Sx compared to S0.
1. Will the responses be slower when the system is powered off?
Yes. Gael mentioned the ME powering off (or AMT being powered only in the S0 state), but even assuming the ME is powered, the system will respond slower in an Sx state. How much slower is AMT generation dependent, for instance the platform that is about to be released (AMT 7.0) is significantly faster in Sx, but it will be somewhat slower than when the system is in S0. This is dueto a variety of factors,but mainly that there are moreresourcespowered and available in S0.
2. Why am I getting some non-responses from AMTon anenumerate?
Given how you described performing theenumerate (a loop of 10 requests), it's possible that you are encountering AMT enumeration context limit.In AMT 6, thereis a limit of 3 active enumeration contexts. One possibility given the number of requests and how fast you are performing them, there's a possibility that the context's aren't freeing up before a new request comes in, meaning you would get an error back.
3. Why is ping not always responding?
This is not as clear cut as the previous answer, but one possibility is that the behavior has a similar cause.Ifthe ping is operating at the same time as the enumerations, there's a possibility that the ME is processing other requests and isn't responding before the ping considers the request timed out. I'm not sure what you are using for ping, or howquicklyit assumes a timeout, but that is a possibility.
4.Why is AMT not responding after I unplug the system and plug it back in?
When you unplug the system, it's losing it's DHCP address. I think this could be specific to the platform (given the behavior Rick saw), but there's a possibility that the system isn't requesting a new IP address until the system is powered on again. I see the same behavior you on my system when I pull the power and plug it back in.
For questions 2 and 3, one of my questions to you would be if you see the same behavior when the system is powered on (in an S0 state). If you don't, then likely it is related to AMT responding slower in Sx compared to S0.
Link Copied
7 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It does take time to wake up the ME when it is in a low power state. It cannot respond until it reaches the M1/M3 state. Could you try this with the power policy where the ME is always on? You can take a look at this blog too - it attempts to explain what is happening when you wake up the ME.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Gael,
I'm using AMT version 6.0.3-build 1195 and available power policy is two only
I'm using AMT version 6.0.3-build 1195 and available power policy is two only
Desktop: ON in S0
Desktop: ON in S0, ME Wake in S3, S4-5
If I change to Desktop: ON in S0 means AMT will go off when Host is shutdown. Correct me if I'm wrong.
I'm looking for option to communicate to AMT irrespective of Host status.
As you mentioned in the blog
"Once the ME is "awake" in the M1/M3 state it can process AMT commands and the system can now be powered up via a remote manageability application"
I have chossen power policy Desktop: ON in S0, ME Wake in S3, S4-5, in that case AMT should be wake only. Correct me If I'm wrong.
Thanks,
Mani
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mani,
You definitely want the option for ON in S0, ME Wake in S3, S4-5. One of the points Iwas trying to make in my blog was that it simply takes a little longer to wake up the ME - you don't want to have it power off completely when the Host is not operational because then you wouldn't be able to access AMT unless they system was actually powered up.
You can adjust how long it takes for the ME to "go to sleep" by calling the IdleWakeTimeout API (see the Implementation and Reference Guide for more details.)
The maximum amount of time that you can change the timeout to is 65536 minutes(which is around 45 days...)
You definitely want the option for ON in S0, ME Wake in S3, S4-5. One of the points Iwas trying to make in my blog was that it simply takes a little longer to wake up the ME - you don't want to have it power off completely when the Host is not operational because then you wouldn't be able to access AMT unless they system was actually powered up.
You can adjust how long it takes for the ME to "go to sleep" by calling the IdleWakeTimeout API (see the Implementation and Reference Guide for more details.)
The maximum amount of time that you can change the timeout to is 65536 minutes(which is around 45 days...)
IdleWakeTimeout
public uint32 IdleWakeTimeout
- General Information:
Defines the minimum time value, in minutes, that Intel AMT will be powered after waking up from a sleep power state, or after the host enters sleep or off state.This timer value will be reloaded whenever Intel AMT is servicing requests. Note: this setting may not be applicable under some power package definitions.
Product Specific Usage:
The minimum value for this property is 1, maximum is 65535
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Gael,
When Host(windows7) is shutdown and i tried enumerate CIM_ComputerSytem for 10 times, around 6 times got the response and 4 times failed. I also tried ping -t ipaddress, first 2 or 3 times got request timeout and got ping response, but frequently getting request timeout after every 5-10 ping response.
Once ME is in Wake state it has to given response, correct me if I'm wrong?
Another scenario i tried is shutdown host and remove power cabe, connect power cable again and enumerate CIM_ComputerSytem for 10 times, it fails all 10 times. Why it's failing all 10 times?
In all cases power policy is ON in S0, ME Wake in S3, S4-5
When host is in shutdown state AMT response varies, I tried increased Idle Time out in MEBx configuration with value as 2000, after that also AMT is not responding for all ping
Executedarp -a ipaddress command and tried ping ,getting request timeout frequently.
Will AMT be in wake up state(for atleas 30-45 Minutes, Idle time out setting is 2000)after giving Nudge event?
Thanks,
Mani
When Host(windows7) is shutdown and i tried enumerate CIM_ComputerSytem for 10 times, around 6 times got the response and 4 times failed. I also tried ping -t ipaddress, first 2 or 3 times got request timeout and got ping response, but frequently getting request timeout after every 5-10 ping response.
Once ME is in Wake state it has to given response, correct me if I'm wrong?
Another scenario i tried is shutdown host and remove power cabe, connect power cable again and enumerate CIM_ComputerSytem for 10 times, it fails all 10 times. Why it's failing all 10 times?
In all cases power policy is ON in S0, ME Wake in S3, S4-5
When host is in shutdown state AMT response varies, I tried increased Idle Time out in MEBx configuration with value as 2000, after that also AMT is not responding for all ping
Executedarp -a ipaddress command and tried ping ,getting request timeout frequently.
Will AMT be in wake up state(for atleas 30-45 Minutes, Idle time out setting is 2000)after giving Nudge event?
Thanks,
Mani
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mani-
I'm not sure why you are seeing the behavior you are. I've done some similar simple ping testing on my box and it is behavingas exepected. I have the IdleWakeTimeout set to 3 (which is about 3 minutes), system is powered down, after about 4-5 minutes I ping the box and the intial attempts fail then they start working. Same happens after I unplug and re-plug the power cord. One difference is my system has a 6.0.3.1208 build. Are you working on an OEM system? If so, does the OEM have a FW upgrade available?
Also, can you describe your testing environment? Are the client and console you are using on the same subnet? Any network devices in between? etc. Also how quickly are you retrying/resending your attempts?
The command/packet first sent to a "sleeping" ME (one were the IdleWakeTimout timer has expired) is lost. By that I mean it wakes the ME up, but it is not buffered/saved for the ME to act upon once it is awake. So, if the ME is asleep, it is expected to have the first AMT command timeout andthere is a need to resend the command. But, once it is up and awake, the ME should respond; you may not have100% responsesuccess but as long as your algorithm has a small delay and resend(if request does happen to timeout for any reason) you should be seeing good results.
-RB
I'm not sure why you are seeing the behavior you are. I've done some similar simple ping testing on my box and it is behavingas exepected. I have the IdleWakeTimeout set to 3 (which is about 3 minutes), system is powered down, after about 4-5 minutes I ping the box and the intial attempts fail then they start working. Same happens after I unplug and re-plug the power cord. One difference is my system has a 6.0.3.1208 build. Are you working on an OEM system? If so, does the OEM have a FW upgrade available?
Also, can you describe your testing environment? Are the client and console you are using on the same subnet? Any network devices in between? etc. Also how quickly are you retrying/resending your attempts?
The command/packet first sent to a "sleeping" ME (one were the IdleWakeTimout timer has expired) is lost. By that I mean it wakes the ME up, but it is not buffered/saved for the ME to act upon once it is awake. So, if the ME is asleep, it is expected to have the first AMT command timeout andthere is a need to resend the command. But, once it is up and awake, the ME should respond; you may not have100% responsesuccess but as long as your algorithm has a small delay and resend(if request does happen to timeout for any reason) you should be seeing good results.
-RB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Are the client and console you are using on the same subnet?
Yes, client and console on same subnet
Any network devices in between?
Yes, Have switch between AMT machine and Console
Also how quickly are you retrying/resending your attempts?
I'm sending command immediately after getting reply(failure only). I tried for 10 times in for loop
I'm using AMT version 6.1.1.1045
Thanks,
Mani
Are the client and console you are using on the same subnet?
Yes, client and console on same subnet
Any network devices in between?
Yes, Have switch between AMT machine and Console
Also how quickly are you retrying/resending your attempts?
I'm sending command immediately after getting reply(failure only). I tried for 10 times in for loop
I'm using AMT version 6.1.1.1045
Thanks,
Mani
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Let me go through what I believe are your three four questions currently
1. Will the responses be slower when the system is powered off?
Yes. Gael mentioned the ME powering off (or AMT being powered only in the S0 state), but even assuming the ME is powered, the system will respond slower in an Sx state. How much slower is AMT generation dependent, for instance the platform that is about to be released (AMT 7.0) is significantly faster in Sx, but it will be somewhat slower than when the system is in S0. This is dueto a variety of factors,but mainly that there are moreresourcespowered and available in S0.
2. Why am I getting some non-responses from AMTon anenumerate?
Given how you described performing theenumerate (a loop of 10 requests), it's possible that you are encountering AMT enumeration context limit.In AMT 6, thereis a limit of 3 active enumeration contexts. One possibility given the number of requests and how fast you are performing them, there's a possibility that the context's aren't freeing up before a new request comes in, meaning you would get an error back.
3. Why is ping not always responding?
This is not as clear cut as the previous answer, but one possibility is that the behavior has a similar cause.Ifthe ping is operating at the same time as the enumerations, there's a possibility that the ME is processing other requests and isn't responding before the ping considers the request timed out. I'm not sure what you are using for ping, or howquicklyit assumes a timeout, but that is a possibility.
4.Why is AMT not responding after I unplug the system and plug it back in?
When you unplug the system, it's losing it's DHCP address. I think this could be specific to the platform (given the behavior Rick saw), but there's a possibility that the system isn't requesting a new IP address until the system is powered on again. I see the same behavior you on my system when I pull the power and plug it back in.
For questions 2 and 3, one of my questions to you would be if you see the same behavior when the system is powered on (in an S0 state). If you don't, then likely it is related to AMT responding slower in Sx compared to S0.
1. Will the responses be slower when the system is powered off?
Yes. Gael mentioned the ME powering off (or AMT being powered only in the S0 state), but even assuming the ME is powered, the system will respond slower in an Sx state. How much slower is AMT generation dependent, for instance the platform that is about to be released (AMT 7.0) is significantly faster in Sx, but it will be somewhat slower than when the system is in S0. This is dueto a variety of factors,but mainly that there are moreresourcespowered and available in S0.
2. Why am I getting some non-responses from AMTon anenumerate?
Given how you described performing theenumerate (a loop of 10 requests), it's possible that you are encountering AMT enumeration context limit.In AMT 6, thereis a limit of 3 active enumeration contexts. One possibility given the number of requests and how fast you are performing them, there's a possibility that the context's aren't freeing up before a new request comes in, meaning you would get an error back.
3. Why is ping not always responding?
This is not as clear cut as the previous answer, but one possibility is that the behavior has a similar cause.Ifthe ping is operating at the same time as the enumerations, there's a possibility that the ME is processing other requests and isn't responding before the ping considers the request timed out. I'm not sure what you are using for ping, or howquicklyit assumes a timeout, but that is a possibility.
4.Why is AMT not responding after I unplug the system and plug it back in?
When you unplug the system, it's losing it's DHCP address. I think this could be specific to the platform (given the behavior Rick saw), but there's a possibility that the system isn't requesting a new IP address until the system is powered on again. I see the same behavior you on my system when I pull the power and plug it back in.
For questions 2 and 3, one of my questions to you would be if you see the same behavior when the system is powered on (in an S0 state). If you don't, then likely it is related to AMT responding slower in Sx compared to S0.
![](/skins/images/7B0AB6865064EAE32B30EC9A4E94B48A/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page