PSP2000怎么看小说?请详细解说

Posted 2023-04-25

http://psp.tgbus.com/zt/psp/software/index.html PSP游戏ISO压缩软件 1-简约的压缩/解压软件Ciso_Utility_0.7 中文版 Ciso_Utility_0.7 中文版，简单易用的ISO转换软件 2-ISO/DAX/CSO/JSO转换软件 PSP ISO Compressor 1.4汉化版 PSP ISO Compressor是一个强大的PSP游戏镜像压缩和转换工具，目前最新1.4版本还加入了一个比CSO更加高效的压缩格式JSO，它的压缩比目前是最高的。PSP ISO Compres PSP游戏ISO压缩工具YACC v0.3.9.0(汉化版) PSP上好用的游戏ISO压缩工具YACC全名为Yet another Cso compressor ，自从0.39版开始加入Cisoplus 的支持后，YACC可压缩cso了PS模拟游戏转换软件 1-PS ISO 转换工具 Simple PopStation GUI v3.00 BETA 中文版 软件介绍该有的功能都有了，界面比 PSX2PSP 漂亮，功能比 icetea 强，预览功能非常漂亮，有前途啊 1、转换成PSP格式可直接运行，不需要 Keys.bin 文件 2、包含图片、图标 2-PS ISO 转换工具 清爽冰茶 icetea v1.3 中文汉化版 软件介绍 DA大神放出OE-C，相信很多人已经喜刷刷了，对应的PS ISO转换软件popstation.exe 也得以升级，增加功能：不需要Key.bin文件直接运行EBOOT.PBP格式的PS游 3-PS ISO转换工具 PSX2PSP v1.2 b2汉化版 软件介绍 PSX2PSP 又更新了，是 v1.2 版，界面很漂亮，喜欢的下吧： b2修正一处翻译错误！ v1.2版更新内容： 1、修正 popstation.dll 文件的 bugs ... 4-PS攻略创建器 PSP DocMaker GUI v0.21 汉化版 软件介绍这个软件是PSP上面的PS游戏模拟器支持的说明文档 document.dat 的图形化生成软件，它支持 .txt文本文件和 .png；.gi；;.cur；.pcx；.ani；.jpg。PSP记忆棒工具 1-购买记忆棒必备软件：测速软件blackSPEED2.0版发布 blackSPEED是一款很好用的记忆棒测试软件，它能精确地检测出你记忆棒的性能，最新为2.0版。更新： 1.更高的精确度 2.速度优化 3.测试结果页面自动截图功能 4.新的图形用户界面 2-组棒必备！诺顿磁盘医生 NDD2006 简体中文汉化版 软件介绍相信CG很多XD小P的棒子都是组的，优点不说了，缺点有一个，就是不稳定，反复Copy、Delete后很容易出现存储逻辑错误，另外在Copy中出现传输错误时，也会出问题。 PSP文件管理软件 1-PSP文件管理神器！PSP Filer 详细使用教程 PSP的文件管理神器 filer 本软件应该是PSP上最好的文件管理器只要熟悉它，对PSP的文件管理将变得轻松化只要记住L+R+左键 慎用！尤其不熟悉的朋友，这个组合键不要随意使用... 2-PSP 个人媒体管理器 Personal Media Manager v2.9 中文版 软件介绍 PSP多功能管理器Personal Media Manager v2.90，是一个强大的针对PSP玩家的个人多媒体管理器，新版最大的改进就是支持了RealMedia(.RM和.RMVB) 3-PSP MP4文件管理软件 PSP Video Manager v1.2.0.5 中文版 软件介绍 PSP Video Manager 是一个管理 PSP 上的官方 MP4 视频文件的工具软件，目前版本为 1.2.0.5，包含的功能如下： 1、支持 PC 和 PSP 之间 MP4 视频 4-PSP工具软件集合 Yet Another PSP Toolkit 1.0 中文汉化版 软件介绍 Yet Another PSP Toolkit 1.0 是一个 PSP 工具软件的集合体，目前 1.0 是预览版，包含的功能如下： PSP ISO 镜像转换 PSX ISO 镜像转换 PSP游戏RIP工具 1-PS ISO Rip 工具 PSX Ultra Ripper v0.2 中文汉化测试版 软件介绍你会觉得把PS游戏传到PSP中很慢吗？由SamL制作的PS游戏瘦身软件 PSX Ultra Ripper v0.2 可以帮助你解决这些问题。PSX Ultra Ripper v0.2界面 2-PSP ISO 究极 RIP 工具 Ultimate RipKit v1.0 汉化版 软件介绍 PSP 究极 RIP 工具 Ultimate RipKit v1.0 发布 ，简单来说这个一个非常华丽又非常傻瓜的给你的PSP完整版 ISO 打上 RIP 补丁的好工具，另外还支持 PSP视频转换工具 PSP视频播放工具 PSP视频播放软件PMPlayer advance(PPA) 完美支持PMPAVC[使用教程] PSP视频播放器PMP Mod AVC v1.02M-K字幕版 PMPAVC视频播放PSP多功能视频PSPlayer Media Test(PSPlayerMT) 多种其他格式视频播放PSP看图书软件 PSP专用看漫画软件PSPComic v0.9.7 Beta看电子书软件ereader(TXT等)其他 PSP 连接 PC 管理工具 PSPHost 2.0 中文汉化版 软件介绍 PSPHost是一个 USBHOSTFS，NETHOSTFS，WiFiController 和 PiMPStreamer 等PSP专用程序的启动管理界面设定工具，也就是说它可以让你非常另外还有几个软件挺全的地址： http://www.gold3.cn/Soft/ http://www.psp110.com/dd/html/PSPruanjianxiazai/index.html 参考技术A 先下载一个xReader，然后解压，将解压后得到的xReader文件夹放到PSP/GAME中，然后随便去哪个网站下载TXT格式的电子书，放进PSP里，运行xReader就可以看了（电子书可以放到任意的文件夹中，你可以通过xReader找到）xReader下载地址： http://psp.tgbus.com/hb/200807/20080725094754.shtml本回答被提问者采纳

iostat和iowait详细解说

简单的说,sar -u看出来的cpu利用率iowait 不实用，iostat -x 中的 svctm   和util 参数

命令形式: iostat -x 1

每隔一秒输出下

其中的svctm参数代表平均每次设备I/O操作的服务时间 (毫秒)，反应了磁盘的负载情况，如果该项大于15ms，并且util%接近100%，那就说明，磁盘现在是整个系统性能的瓶颈了。

await 参数代表平均每次设备I/O操作的等待时间 (毫秒)， 也要多和 svctm 来参考。差的过高就一定有 IO 的问题。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢。

正常情况下svctm应该是小于await值的，而svctm的大小和磁盘性能有关，CPU、内存的负荷也会对svctm值造成影响，过多的请求也会间接的导致svctm值的增加。
await值的大小一般取决与svctm的值和I/O队列长度以及I/O请求模式，如果svctm的值与await很接近，表示几乎没有I/O等待，磁盘性能很好，如果await的值远高于svctm的值，则表示I/O队列等待太长，系统上运行的应用程序将变慢，此时可以通过更换更快的硬盘来解决问题。
%util项的值也是衡量磁盘I/O的一个重要指标，如果%util接近100%，表示磁盘产生的I/O请求太多，I/O系统已经满负荷的在工作，该磁盘可能存在瓶颈。长期下去，势必影响系统的性能，可以通过优化程序或者通过更换更高、更快的磁盘来解决此问题

svctm一项正常时间在20ms左右，原因：

高速cpu会造成很高的iowait值，但这并不代表磁盘是系统的瓶颈。唯一能说明磁盘是系统瓶颈的方法，就是很高的read/write时间，一般来说超过20ms，就代表了不太正常的磁盘性能。为什么是20ms呢？一般来说，一次读写就是一次寻到+一次旋转延迟+数据传输的时间。由于，现代硬盘数据传输就是几微秒或者几十微秒的事情，远远小于寻道时间2~20ms和旋转延迟4~8ms，所以只计算这两个时间就差不多了，也就是15~20ms。只要大于20ms，就必须考虑是否交给磁盘读写的次数太多，导致磁盘性能降低了。

%iowait并不能反应磁盘瓶颈

iowait实际测量的是cpu时间：
%iowait = (cpu idle time)/(all cpu time)

iostat来对linux硬盘IO性能进行了解

以前一直不太会用这个参数。现在认真研究了一下iostat，因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器

$iostat -x 1
Linux 2.6.33-fukai (fukai-laptop)          _i686_    (2 CPU)
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
5.47    0.50    8.96   48.26    0.00   36.82

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               6.00   273.00   99.00    7.00  2240.00  2240.00    42.26     1.12   10.57   7.96  84.40
sdb               0.00     4.00    0.00  350.00     0.00  2068.00     5.91     0.55    1.58   0.54  18.80

rrqm/s:          每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s:         每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s:            每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s:            每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s:         每秒读扇区数。即 delta(rsect)/s
wsec/s:         每秒写扇区数。即 delta(wsect)/s
rkB/s:          每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)
wkB/s:          每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz:       平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz:       平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await:          平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm:          平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util:          一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)

如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。

idle小于70% IO压力就较大了,一般读取速度有较多的wait。

同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)

另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。

avgqu-sz 也是个做 IO 调优时需要注意的地方，这个就是直接每次操作的数据的大小，如果次数多，但数据拿的小的话，其实 IO 也会很小.如果数据拿的大，才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲，读定速度是这个来决定的。

另外还可以参考

svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。

队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。

别人一个不错的例子(I/O 系统 vs. 超市排队)

举一个例子，我们在超市排队 checkout 时，怎么决定该去哪个交款台呢? 首当是看排的队人数，5个人总比20人要快吧? 除了数人头，我们也常常看看前面人购买的东西多少，如果前面有个采购了一星期食品的大妈，那么可以考虑换个队排了。还有就是收银员的速度了，如果碰上了连钱都点不清楚的新手，那就有的等了。另外，时机也很重要，可能 5 分钟前还人满为患的收款台，现在已是人去楼空，这时候交款可是很爽啊，当然，前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。

I/O 系统也和超市排队有很多类似之处:

r/s+w/s 类似于交款人的总数

平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数

平均服务时间(svctm)类似于收银员的收款速度

平均等待时间(await)类似于平均每人的等待时间

平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少

I/O 操作率 (%util)类似于收款台前有人排队的时间比例。

我们可以根据这些数据分析出 I/O 请求的模式，以及 I/O 的速度和响应时间。

下面是别人写的这个参数输出的分析

# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29

上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。

平均每次设备 I/O 操作只需要 5ms 就可以完成，但每个 I/O 请求却需要等上 78ms，为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个)，假设这些请求是同时发出的，那么平均等待时间可以这样计算:

平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + … + 请求总数-1) / 请求总数

应用到上面的例子: 平均等待时间 = 5ms * (1+2+…+28)/29 = 70ms，和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。

每秒发出的 I/O 请求很多 (约 29 个)，平均队列却不长 (只有 2 个左右)，这表明这 29 个请求的到来并不均匀，大部分时间 I/O 是空闲的。

一秒中有 14.29% 的时间 I/O 队列中是有请求的，也就是说，85.71% 的时间里 I/O 系统无事可做，所有 29 个 I/O 请求都在142毫秒之内处理掉了。

delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8，表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23，而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35，为什么?! 因为 iostat 中有 bug，avgqu-sz 值应为 2.23，而不是 22.35