author | Robert Tivy <rtivy@ti.com> | |
Thu, 27 Feb 2014 02:08:05 +0000 (18:08 -0800) | ||
committer | Chris Ring <cring@ti.com> | |
Sun, 2 Mar 2014 17:46:20 +0000 (09:46 -0800) | ||
commit | 64cff59ff8df8ccc1746e8f53989f34fd59ad3c3 | |
tree | b1456586187e070c8ab39c646977876a465cc6a6 | tree | snapshot (tar.xz tar.gz zip) |
parent | f816f6ebcc15e442cddda8df3dac56341c698bf7 | commit | diff |
Increase NAMESERVER_GET_TIMEOUT from 20000 to 40000 microseconds
Product testing revealed that a remote core was occasionally taking
slighly longer than 20000 microseconds to respond (in the negative)
to a NameServer_getRemote() query. We're not sure why it's taking
so long in some cases, as normally the remote core will respond in a
few hundred microseconds.
Doubling the timeout will affect the total query time across multiple
remote cores when some of those cores aren't running NameServer, but
this should be OK since it affects "startup" times with MessageQ_open()
and shouldn't affect normal "execute" times.
Product testing revealed that a remote core was occasionally taking
slighly longer than 20000 microseconds to respond (in the negative)
to a NameServer_getRemote() query. We're not sure why it's taking
so long in some cases, as normally the remote core will respond in a
few hundred microseconds.
Doubling the timeout will affect the total query time across multiple
remote cores when some of those cores aren't running NameServer, but
this should be OK since it affects "startup" times with MessageQ_open()
and shouldn't affect normal "execute" times.
hlos_common/include/_NameServerRemoteRpmsg.h | diff | blob | history |