Hi Rob, mentioning the error-log: can you take a look at the time-formatting of the -trace_msg logs?
Currently, they are formatted as 2013-02-16 23:40:21:589.216 which is incorrect. The correct (parseable) formatting should (IMHO) be 2013-02-16 23:40:21.589216 (as the ms und us are fractions of a second). Additionally, the leading zeros of the microseconds are removed. E.g. instead of 2013-02-16 23:40:21:573.012 SIPp formats it as 2013-02-16 23:40:21:573.12 The -trace_shortmsg-logs are not affected, as these logs contain the unix-timestamps 1361058600.182012. Well, but in this context: the timestamps of the trace_msg and trace_shortmsg differ. The reason for this behaviour is the point of time when the timestamp is stored. This is done in different lines in the code resulting in different timestamps. Thanks for your contribution! BR Michael Am 15.02.2013 23:37, schrieb Rob Day: > Hi all, > > I've uploaded the SIPp 3.3 packages, and now that that release is > complete, I'm planning what to include in SIPp 3.4. My current > thoughts are: > > * Review and potential inclusion of patches at > https://sourceforge.net/p/sipp/patches/milestone/v3.4/ > * Fixes for bugs at > https://sourceforge.net/p/sipp/bugs/milestone/v3.4/ (excepting perhaps > the RTP threading issues) > * Port from OpenSSL to GnuTLS (for licensing reasons) > * Add a ./configure option to enable the GNU Scientific Libraries > * Logging improvements: > * Short error log - every minute (or other time period determined by > -fd), print out a list of SIP error codes received (e.g. <timestamp>: > 503 404 486 486 503 500) > * RTP error log - log timestamps (and possibly other data) for each > incoming/outgoing RTP packet. This is actually a reasonably chunky > piece of work: SIPp doesn’t do any RTP parsing or understand RTP > packets at the moment, it just sends them straight through. > * Codebase cleanup - the SIPp codebase could be made a little more > consistent and friendly to new developers (e.g. better commenting, > better documentation of the program flow and structure, more > consistency in indentation and whether function names use underscores > or camelCase), so I intend to spend some time on this. > > There's also a possibility that one or two companies will contribute > back some in-house changes to SIPp which they've made in the last > couple of years, but I'm not yet sure what those changes consist of. > > I made several commits yesterday, as the start of v3.4 work: these > fixed a bug where SIPp used 100% CPU when at its call rate limit, and > cleaned up the codebase in various ways (compiling without GCC errors, > fixing cppcheck warnings, and formatting). I've broken them down into > multiple small commits, so if anyone wants to review them, it > shouldn't be an overwhelming job. > > Best, > Rob > > ------------------------------------------------------------------------------ > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, > is your hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials, tech docs, > whitepapers, evaluation guides, and opinion stories. Check out the most > recent posts - join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Sipp-users mailing list > Sipp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sipp-users > ------------------------------------------------------------------------------ The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
